MS certutil -verify fails for cert.pem and fullchain.pem. Why?

Help
1

Microsofts internal cert verification components throw an error. Tested with certutil:

I ran this command: certutil -verify -urlfetch cert.pem

It produced this output: Aussteller:
CN=Let’s Encrypt Authority X3
O=Let’s Encrypt
C=US
Namenshash (sha1): 7ee66ae7729ab3fcf8a220646c16a12d6071085d
Namenshash (md5): c0350a4a6f6b94d938b5003a57bb4867
Antragsteller:
CN=www.mydomain.de
Namenshash (sha1): 0a45f24e027192b7863afb1e0896e88a94c74305
Namenshash (md5): 6bdef80a3a02c62b498e6a554094b1ed
Zertifikatseriennummer: 034dde82f2a0e66c92ee29ebede3fa80e6c7

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, 13 Hours, 20 Minutes, 36 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 1 Days, 13 Hours, 20 Minutes, 36 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US
NotBefore: 11.05.2017 02:38
NotAfter: 09.08.2017 02:38
Subject: CN=www.mydomain.de
Serial: 034dde82f2a0e66c92ee29ebede3fa80e6c7
SubjectAltName: DNS-Name=mydomain.de, DNS-Name=mydomain.eu, DNS-Name=www.mydomain.de, DNS-Name=www.mydomain.eu
Cert: c4ea64889db020e794a247293944a18b5ec3177b
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Zertifikat abrufen ----------------
Überprüft “Zertifikat (0)” Zeit: 0
[0.0] http://cert.int-x3.letsencrypt.org/

---------------- Zertifikat abrufen ----------------
Keine URLs “Keine” Zeit: 0
---------------- Basissperrliste veraltet ----------------
Keine URLs “Keine” Zeit: 0
---------------- Zertifikat-OCSP ----------------
Überprüft “OCSP” Zeit: 0
[0.0] http://ocsp.int-x3.letsencrypt.org/

CRL (null):
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
ThisUpdate: 17.05.2017 03:00
NextUpdate: 24.05.2017 03:00
CRL: 8892a5c37e9e1b18b6d7cf54acdc6d86e0809e95

Issuance[0] = 2.23.140.1.2.1
Issuance[1] = 1.3.6.1.4.1.44947.1.1.1
Application[0] = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung
Application[1] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co.
NotBefore: 17.03.2016 18:40
NotAfter: 17.03.2021 18:40
Subject: CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US
Serial: 0a0141420000015385736a0b85eca708
Cert: e6a3b45b062d509b3382282d196efe97d5956ccb
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Zertifikat abrufen ----------------
Überprüft “Zertifikat (0)” Zeit: 0
[0.0] http://apps.identrust.com/roots/dstrootcax3.p7c

---------------- Zertifikat abrufen ----------------
Überprüft “Basissperrliste (aa)” Zeit: 0
[0.0] http://crl.identrust.com/DSTROOTCAX3CRL.crl

---------------- Basissperrliste veraltet ----------------
Keine URLs “Keine” Zeit: 0
---------------- Zertifikat-OCSP ----------------
Überprüft “OCSP” Zeit: 0
[0.0] http://isrg.trustid.ocsp.identrust.com

CRL (null):
Issuer: E=pki-ops@IdenTrust.com, CN=DST CA X3 OCSP Signer, OU=DST, O=Digital Signature Trust, C=US
ThisUpdate: 18.05.2017 11:26
NextUpdate: 19.05.2017 11:26
CRL: eb82fdefaeabf9244e9c8fc1c052797fa08edd94

Issuance[0] = 2.23.140.1.2.1
Issuance[1] = 1.3.6.1.4.1.44947.1.1.1
Application[0] = 1.3.6.1.5.5.7.3.4 Sichere E-Mail
Application[1] = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung
Application[2] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung
Application[3] = 1.3.6.1.5.5.7.3.8 Zeitstempel
Application[4] = 1.3.6.1.4.1.311.10.3.4 Verschlüsselndes Dateisystem
Application[5] = 1.3.6.1.4.1.311.10.3.12 Dokumentsignatur

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co.
NotBefore: 30.09.2000 23:12
NotAfter: 30.09.2021 16:01
Subject: CN=DST Root CA X3, O=Digital Signature Trust Co.
Serial: 44afb080d6a327ba893039862ef8406b
Cert: dac9024f54d8f6df94935fb1732638ca6ad77c13
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)
---------------- Zertifikat abrufen ----------------
Keine URLs “Keine” Zeit: 0
---------------- Zertifikat abrufen ----------------
Keine URLs “Keine” Zeit: 0
---------------- Zertifikat-OCSP ----------------
Keine URLs “Keine” Zeit: 0

Application[0] = 1.3.6.1.5.5.7.3.4 Sichere E-Mail
Application[1] = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung
Application[2] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung
Application[3] = 1.3.6.1.5.5.7.3.8 Zeitstempel
Application[4] = 1.3.6.1.4.1.311.10.3.4 Verschlüsselndes Dateisystem
Application[5] = 1.3.6.1.4.1.311.10.3.12 Dokumentsignatur

Exclude leaf cert:
Chain: 8b7ab36ece90ebb699b18f9d2bfafc4c6bc4d40f
Full chain:
Chain: 7e00edb48331966cc2699a2c8e01ce0e21803e4d
Issuer: CN=Let’s Encrypt Authority X3, O=Let’s Encrypt, C=US
NotBefore: 11.05.2017 02:38
NotAfter: 09.08.2017 02:38
Subject: CN=www.mydomain.de
Serial: 034dde82f2a0e66c92ee29ebede3fa80e6c7
SubjectAltName: DNS-Name=mydomain.de, DNS-Name=mydomain.eu, DNS-Name=www.mydomain.de, DNS-Name=www.mydomain.eu
Cert: c4ea64889db020e794a247293944a18b5ec3177b
Das Objekt oder die Eigenschaft wurde nicht gefunden. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)

CertUtil: -verify-Befehl ist fehlgeschlagen: 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
CertUtil: Das Objekt oder die Eigenschaft wurde nicht gefunden.

My operating system is (include version): Windows 10

2

Hi @prisma

The best way of doing this would be to paste screenshots of how you are applying the client certificate to WinSCP and FileZilla Also I have updated your heading so others can help out

Hints at: https://winscp.net/eng/docs/tls

Andrei

3

Hello aha021,

THX that you tried to help. But I think it’s a misunderstanding. It’s not about configuring WinSCP or FiIlezilla, it’s about MS certutil.exe verify fails. The question is WHY? Failing WinSCP and Filezilla is the consequence because they use the same libraries.

Cheers

4

@prisma

I will be blunt - if i am not understanding it’s because you are not explaining. So please explain what you are trying to do and we will see if we can figure out why things aren’t working.

Why do you run this command certutil -verify -urlfetch cert.pem - what are you hoping to achieve? What are you expecting the results to be?

Andrei

5

I’m really sorry for your inconvenience, seriously. But I already wrote what I’m doing and why I’m doing this. This leaded to a misunderstanding that it is an isolated problem of a file transfer client configuration. But it isn’t. So I edited myself this post, deleted all the explaining stuff why I came to the point where I was forced to do a cross check with a standard windows administration tool (certutil.exe). I just tried to keep it simple and stupid. Now I’m not explaining enough?

I’m expecting that a certificate check with a standard windows tool, used from every windows cert admin in the world, is completed successfully. I’m not necessarily saying that let’s encrypt does something wrong, but may be they do. But also may be it’s a windows related problem. This I’m trying to investigate. I’m not understanding why CRYPT_E_NOT_FOUND is thrown and I need help. That’s all.

6

used from every windows cert admin in the world, is completed successfully

that is an assumption

however lets take a breather

A) I have written two articles on how to use LetsEncrypt with Windows

https://www.linkedin.com/pulse/lets-encrypt-part-2-3-repurposing-clients-making-things-andrei-hawke

Neither of these make a use of Certutil but instead use MMC plugins.

I will also be honest and say that I haven't had a Microsoft Certification since Windows Server 2008. It may be that microsoft strongly recommends the use of Certutil but it is not a tool I have ever had to use (and we deploy SSL certs in a wide range of Microsoft Environments). All our own IIS 8.5, RDP and SQL environments use Let's Encrypt Certificates and I have not had any issues at all.

From here I will review what you are pasting and try to replicate what you are doing. Once I have more information I will post back.

Andrei

7

hi @prisma

I suspect you do not have the Let’s Encrypt Intermediate Certificate Installed. You can verify in MMC

image.png835×269 27.3 KB

I can run the verify command on Windows 7 with no issues

image.png856×256 4.64 KB

Andrei

8

Hi Andrei,

I’ll try to answer structured, as short as possible:

  1. My initial post/problem regarding errors with WinSCP and Filezilla is explained by the letsencrypt OCSP blackout starting last THU ending FRI. So it’s been a completely letsencrypt home made problem. Thank you to letsencrypt, this took me hours of senseless investigation.
  2. Unfortunately this leaded me to using a independent test tool like certutil.exe. But the thrown error came out to be a Windows 10 related problem!! Thank you to Microsoft at that point.
  3. Regarding installation of intermediate certificates: The need of installing intermediate certificates would lead the whole chain of trust to absurdity. The chain of trust is verifiable by only trusting the root CA as long the server delivers the chain certs also. Which is given.

Tested on Win7, certutil.exe is ok, Win10 not. So, my posting now makes sense anyway, because the question is: Why does certutil fail under Win10?

9

Anyway, fullchain.pem contains the intermediate in question, so if certutil is able to accept intermediates in a PEM file, it presumably ought to work.

10

Hi @prisma

Looks like microsoft changed some of the syntax as well

https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx

@schoen - I have confirmed that certutil will not use intermediates in leaf certificates (i.e. fullchain.pem won’t work)

@prisma - I believe certutil is not getting the CRL list from the LetsEncrypt Intermediate. I haven’t isolated this yet but below are my tests

A) Mail.google.com - grab the cert and the intermediate and verify CRL

image.png744×510 17.6 KB

B) Stack Exchange with DigiCert Intermediate

image.png829×531 18.7 KB

C) Let’s Encrypt with Let’s Encrypt Intermediate

You can grab the leaf cert here for your own testing: https://censys.io/certificates/fad639be1e4db4ddb2f7b988be87836b3e3a3d37271876c3e0de82e7ef51365e

image.png743×494 24.2 KB

Where to next:

  • I am trying to figure out why certutil doesn’t like the CRL list in the LE intermediate certificate
  • You definitely need to include the intermediate to avoid the LE errors
  • The easiest way to check revocation is using CRT.SH e.g. the TLS-SNI cert I am using for testing https://crt.sh/?id=132389267
  • Format for Windows 10 Certutil certutil -f -urlfetch -verify CERTIFICATE INTERMEDAITE
  • I know you can also verify the certificates against a local version of CRL so that may also be an option (the CRL is quite small)

Andrei

11

First of all, thank you Andrei for digging deeper. I’m able to confirm that certutil completes successfully, but isn’t able to do the CRL check. On both systems Win7 and Win10. With one big difference:

Win7 certutil completes without being pointed to the intermediate certificate.
Win10 certutil needs the second certutil file parameter, it needs the intermediate, otherwise fails.

Why does a client shouldn’t necessarily need a intermediate certificate for successful cert verification? Because of the AIA extension of the cert! AIA points to the needed intermediate or CA certs. See this picture from Win7:

win7.png2355×1029 148 KB

So, my conclusion is, we have 2 problems:

  1. Win7 is obviously able to use the AIA extension and completes successfully, but NOT Win10
  2. certutil has a problem with the CRL check in general.

As long this doesn’t affect any windows client or function, hey, let’s forget about it.
But I’m afraid certutil just uses standard windows routines and fails anyway. And this definitely could affect any windows client or function.

12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.