Certificates not valid with Deep SSL Inspection

Published 5 years ago

Hey guys,

with our Firewall we do Deep SSL Inspection on every encrypted communication, including HTTPS.
This means that our firewall breaks and decrypts every HTTPS packet, inspects it and encrypts it again.
The re-encryption is done through our internal Certificate Authority CA Certificate.
This means that in the Certificate Chain of for example sni.cloudflaressl.com the original Root CA Certificate is replaced by our internal CA Certificate, due to the re-encrypting.

The downside of this is, that password checks or other RDM services talking to the internet are telling that certificates are not valid.
The internal CA Certificate surely is installed locally.

Is there any posibility to fix this without disabling every SSL Certificate Check in the Settings?

Certificate Validation

All Comments (17)

James Lafleur

Published 5 years ago

Hello Johanne,

Thank you for contacting us on that matter!

In order to prevent you from receiving this error in RDM you would need to check both of these options: KB4451

For more information, please consult this link: https://kb.devolutions.net/rdm_certificate_validation.html

Best regards,

James Lafleur

johannesfankhauser

Published 5 years ago

Hello James,

these two checkboxes are the same in my RDM Client.
I've never changed these, so tis should be the standard config I think?

Best Regards,
Johannes

Jeff Dagenais

Published 5 years ago

Hello,

Sorry, not sure to understand your answer.

Are these 2 options checked or no?

Best regards,

Jeff Dagenais

johannesfankhauser

Published 5 years ago

Hello,

i meant that the checkboxes are identically checked in my installation.

Ignore application certificate error is unchecked
check for server certificate revocation is checked

Best Regards, Johannes

James Lafleur

Published 5 years ago

Hello Johannes,

Thank you for your swift reply and sorry for the confusion. Both options need to be checked:
forum image
Best regards,

James Lafleur

johannesfankhauser

Published 5 years ago

Hello James,

why do I have to ignore the Certificate Checks? This wasn't my intention.
The Certificates the Client gets are Valid and the CA Certificate is also trusted in the root store.
I dont understand why RDM shows that the certs arent valid...?

As mentioned, if i show the certificate the RDM CLient gets, it says its valid.

Here is the Certificate-Diagnose:

Aussteller:
    E=EDV@kreiswerke-main-kinzig.de
    CN=Forti-Sub-CA.kwg2003.intern
    OU=IT
    O=Kreiswerke Main-Kinzig GmbH
    L=Gelnhausen
    S=Hessen
    C=DE
  Namenshash (sha1): 17e08047f209f17d9d1ff0b3c39fae1fd3597eae
  Namenshash (md5): e33cd0cebe9efe0f30cd5369df273eb1
Antragsteller:
    CN=sni.cloudflaressl.com
    O=Cloudflare, Inc.
    L=San Francisco
    S=California
    C=US        
  Namenshash (sha1): b099e4c6d965c0b4c734630df230dce940340ae4
  Namenshash (md5): 64cb3b27e27a2fcd112ae10b803eadc4
Zertifikatseriennummer: 38f54f04a846bcd6

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=4 dwErrorStatus=1000040
  Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
  NotBefore: 06.07.2021 02:00
  NotAfter: 06.07.2022 01:59
  Subject: CN=sni.cloudflaressl.com, O="Cloudflare, Inc.", L=San Francisco, S=California, C="US        "
  Serial: 38f54f04a846bcd6
  SubjectAltName: DNS-Name=pwnedpasswords.com, DNS-Name=*.pwnedpasswords.com, DNS-Name=sni.cloudflaressl.com
  Cert: 668c4db4b0a508249aa27baef3fb659d529cf45d
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
  Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

Exclude leaf cert:
  Chain: da39a3ee5e6b4b0d3255bfef95601890afd80709
Full chain:
  Chain: 668c4db4b0a508249aa27baef3fb659d529cf45d
Missing Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
  Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
  NotBefore: 06.07.2021 02:00
  NotAfter: 06.07.2022 01:59
  Subject: CN=sni.cloudflaressl.com, O="Cloudflare, Inc.", L=San Francisco, S=California, C="US        "
  Serial: 38f54f04a846bcd6
  SubjectAltName: DNS-Name=pwnedpasswords.com, DNS-Name=*.pwnedpasswords.com, DNS-Name=sni.cloudflaressl.com
  Cert: 668c4db4b0a508249aa27baef3fb659d529cf45d
Eine Zertifikatkette zu einer vertrauenswürdigen Stammzertifizierungsstelle konnte nicht aufgebaut werden. 0x800b010a (-2146762486 CERT_E_CHAINING)
------------------------------------
Die Zertifikatkette ist unvollständig.
Folgendes Zertifikat wurde nicht gefunden:
    E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
Das Zertifikat ist ein Endeinheitzertifikat

FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben.
CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

orbanlime

Published 5 years ago

When it comes to creating powerful marketing apps, web developers rely on experienced professional mobile developers. The mobile web platform provided by Apple and Google offers the most flexible app development options available on the market today. Developers from Syndicode need to take advantage of these platforms to create user-friendly, engaging apps that target their specific audience and boost conversion rates. Apple and Google offer both Objective-C and Swift apps that can be easily adapted to native code for optimal compatibility across all devices. Even if your app does not work on iOS, Android, or Windows Phone devices, there are third party solutions available that work with these browsers.

Mathieu Morrissette

Published 5 years ago

Hello James,

why do I have to ignore the Certificate Checks? This wasn't my intention.
The Certificates the Client gets are Valid and the CA Certificate is also trusted in the root store.
I dont understand why RDM shows that the certs arent valid...?

As mentioned, if i show the certificate the RDM CLient gets, it says its valid.

Here is the Certificate-Diagnose:
Aussteller:
E=EDV@kreiswerke-main-kinzig.de
CN=Forti-Sub-CA.kwg2003.intern
OU=IT
O=Kreiswerke Main-Kinzig GmbH
L=Gelnhausen
S=Hessen
C=DE
Namenshash (sha1): 17e08047f209f17d9d1ff0b3c39fae1fd3597eae
Namenshash (md5): e33cd0cebe9efe0f30cd5369df273eb1
Antragsteller:
CN=sni.cloudflaressl.com
O=Cloudflare, Inc.
L=San Francisco
S=California
C=US
Namenshash (sha1): b099e4c6d965c0b4c734630df230dce940340ae4
Namenshash (md5): 64cb3b27e27a2fcd112ae10b803eadc4
Zertifikatseriennummer: 38f54f04a846bcd6

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=4 dwErrorStatus=1000040
Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
NotBefore: 06.07.2021 02:00
NotAfter: 06.07.2022 01:59
Subject: CN=sni.cloudflaressl.com, O="Cloudflare, Inc.", L=San Francisco, S=California, C="US "
Serial: 38f54f04a846bcd6
SubjectAltName: DNS-Name=pwnedpasswords.com, DNS-Name=*.pwnedpasswords.com, DNS-Name=sni.cloudflaressl.com
Cert: 668c4db4b0a508249aa27baef3fb659d529cf45d
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

Exclude leaf cert:
Chain: da39a3ee5e6b4b0d3255bfef95601890afd80709
Full chain:
Chain: 668c4db4b0a508249aa27baef3fb659d529cf45d
Missing Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
Issuer: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
NotBefore: 06.07.2021 02:00
NotAfter: 06.07.2022 01:59
Subject: CN=sni.cloudflaressl.com, O="Cloudflare, Inc.", L=San Francisco, S=California, C="US "
Serial: 38f54f04a846bcd6
SubjectAltName: DNS-Name=pwnedpasswords.com, DNS-Name=*.pwnedpasswords.com, DNS-Name=sni.cloudflaressl.com
Cert: 668c4db4b0a508249aa27baef3fb659d529cf45d
Eine Zertifikatkette zu einer vertrauenswürdigen Stammzertifizierungsstelle konnte nicht aufgebaut werden. 0x800b010a (-2146762486 CERT_E_CHAINING)
------------------------------------
Die Zertifikatkette ist unvollständig.
Folgendes Zertifikat wurde nicht gefunden:
E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
Das Zertifikat ist ein Endeinheitzertifikat

FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben.
CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

Hi,

It seems that the certificate revocation server (CRL) is unreachable since the error is caused by CRYPT_E_REVOCATION_OFFLINE.

You can uncheck the "check for certificate revocation" to disable the revocation check but I would recommend looking into it with the network administrator.

Best regards,
Mathieu Morrissette

Mathieu Morrissette

Published 5 years ago

This is more or less the same problem I had with a WebDav connection.
The access to the CA server, which usually also has the blacklists, is not always possible, publicly because there may be no internet connection and in the own area because this may be operated as offline, which should be so with an own root CA for security reasons.
From my point of view the check of a blocking list is not necessary but only the validation like start/end date and if necessary the encryption (TLS).
This is also how the browsers do it.

johannesfankhauser

Published 5 years ago

Hey guys,

we found out that the intermediate Certificate was missing an URL for the revocation list, and had only an ldap path wich RDM could not resolve.
So we recreated the intermediate Certificate, now containing an http:// url for the revocation list and RDM is still complaining that the revocation couldnt be checked.

So I downloaded the Intermediate Certificate, checked it with certutil.exe -verify and it says it could successfully check the revocation state.

Aussteller:
    CN=kwg2003-intern-CA
    DC=kwg2003
    DC=intern
  Namenshash (sha1): d68341be380027ee513b7f1bc37aafb0e59326d4
  Namenshash (md5): b669595d54c668bc7cbd982e0a1c8799
Antragsteller:
    E=EDV@kreiswerke-main-kinzig.de
    CN=Forti-Sub-CA-intern.kwg2003.intern
    OU=IT
    O=Kreiswerke Main-Kinzig GmbH
    L=Gelnhausen
    S=Hessen
    C=DE
  Namenshash (sha1): d6ccef926a25fe8a08e322c82aa43ffa8a8ca111
  Namenshash (md5): d08b7cdcf5684069676f355ba7bf0a07
Zertifikatseriennummer: 7d0000006b8ebafb8d840812ee00000000006b

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 1 Days, 1 Hours, 59 Minutes, 12 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 1 Days, 1 Hours, 59 Minutes, 12 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=kwg2003-intern-CA, DC=kwg2003, DC=intern
  NotBefore: 17.09.2021 14:34
  NotAfter: 16.09.2026 14:34
  Subject: E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA-intern.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
  Serial: 7d0000006b8ebafb8d840812ee00000000006b
  Template: SubCA
  Cert: 16b76586081fd1b4368633fdf0cac71b0e1bed7b
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 060c:
    Issuer: CN=kwg2003-intern-CA, DC=kwg2003, DC=intern
    ThisUpdate: 16.09.2021 09:06
    NextUpdate: 23.09.2021 21:26
    CRL: 4beaa6443ab835acffa8715f80b414eaddb79bb6
    Delta CRL 0612:
    Issuer: CN=kwg2003-intern-CA, DC=kwg2003, DC=intern
    ThisUpdate: 22.09.2021 09:06
    NextUpdate: 23.09.2021 21:26
    CRL: ddce956b77d3de55a58f3addf9b20f88ec6437fc

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=kwg2003-intern-CA, DC=kwg2003, DC=intern
  NotBefore: 22.06.2017 08:41
  NotAfter: 22.06.2037 08:51
  Subject: CN=kwg2003-intern-CA, DC=kwg2003, DC=intern
  Serial: 557a1fe7426d9ba2493790ff480de0dd
  Template: CA
  Cert: dc7c4930e3fc425c3373bc67986ad263e7b0cfdd
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Exclude leaf cert:
  Chain: e4725dfdf73f39a255e1810fdaa9553559d329c5
Full chain:
  Chain: 3e39cb84457165b995bfda679c8b7375ef3d0c4d
------------------------------------
Verfizierte Ausstellungsrichtlinien: Kein
Verfizierte Anwendungsrichtlinien: Alle
Zertifikat ist ein Zertifizierungsstellenzertifikat
Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlossen.
CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

Mathieu Morrissette

Published 5 years ago

Hi,

I've reimplemented RDM certificate validation in a powershell script (in attachment) to try and diagnose the issue.
You just need to change the $url variable so that it points to your server.

Is it possible to run it and send me the output?

Best regards,
Mathieu Morrissette

Mathieu Morrissette

check-certificate.ps1

johannesfankhauser

Published 5 years ago

Hi Mathieu,

which url should I insert in the variable? We dont have any Devolution Server. We are Using the RDM Client with Microsoft SQL Database Backend.

Best Regards
Johannes

Mathieu Morrissette

Published 5 years ago

Hi,

You can try using any HTTPS endpoint that is problematic.

You could try https://devolutions.net if it is not whitelisted in your Deep Packet Inspection software.

Best regards,

Mathieu Morrissette

johannesfankhauser

Published 5 years ago

Hi,

so here is the Output of your Powershell Script:

Checking  https://login.mittwald.de/ ...
Certificate valid : False
Certificate chain Status Length :  1
Chain status :
RevocationStatusUnknown : Die Sperrfunktion konnte keine Sperrprüfung für das Zertifikat durchführen.


Processing certificate chain...
[LEAF] -  Not Valid  -  CN=mittwald.de, O=Mittwald CM Service GmbH & Co. KG, STREET=Königsberger Str. 4-6, L=Espelkamp, S=Nordrhein-Westfalen, C=DE, SERIALNUMBER=HRA 6640, OID.1.3.6.1.4.1.311.60.2.1.1=Bad Oeynhausen, OID.1.3.6.1.4.1.311.60.2.1.2=Nordrhein-Westfalen, OID.1.3.6.1.4.1.311.60.2.1.3=DE, OID.2.5.4.15="Private Organization                                                                                                                                                                                                                                                                                                             "
Certificate status :  RevocationStatusUnknown
Certificate status information :  Die Sperrfunktion konnte keine Sperrprüfung für das Zertifikat durchführen.

[Intermediate] -     Valid  -  E=EDV@kreiswerke-main-kinzig.de, CN=Forti-Sub-CA-intern.kwg2003.intern, OU=IT, O=Kreiswerke Main-Kinzig GmbH, L=Gelnhausen, S=Hessen, C=DE
[Root] -  CN=kwg2003-intern-CA, DC=kwg2003, DC=intern

Mathieu Morrissette

Published 5 years ago

Hi,

Could it be possible that the CRL endpoint in the leaf certificate is not reachable?

The error seems to indicate that the revocation status couldn't be verified :

Certificate status :  RevocationStatusUnknown
Certificate status information :  Die Sperrfunktion konnte keine Sperrprüfung für das Zertifikat durchführen.

Best regards,

Mathieu Morrissette

johannesfankhauser

Published 5 years ago

Hi,

I wonder why it says this. We recreated the SubCA Intermediate Certificate, because at first the URL of the crl list was missing.
Now as we recreated the SubCA it contains an URL for the crl list and this url is definitely reachable.

Mathieu Morrissette

Published 4 years ago

Hi,

This Mathieu Morrissette from the Devolutions Security Team.

I just wanted to let you know that we have made changes to the certificate validation mechanism in RDM 2021.2.9.0 and above that should solve issues some users were experiencing.

Let us know if you still have the certificate warning message.

Best regards,

Mathieu Morrissette