Problems with cert validation via CRL

David Gray deg at davidegray.com
Thu Feb 23 03:12:42 CET 2017


Thanks very much for getting back to me - I really appreciate your help.  I have been able to get the validation to work by adding the trusted root certificate to the "trusted-certs" folder under the gnupg directory on my windows box.  The directory wasn't there but I was able to add it and as long as the cert is there dirmngr knows that it can trust the CRL that has been issued.  I haven't had a chance to circle back on my Linux installation, but I'm sure the same approach will work.  I'm also not sure how/why the Linux installation was originally able to validate the cert, but I will dig into that.  

Thanks again for your help - it's very much appreciated!

Sent from my Mobile Device

> On Feb 21, 2017, at 9:31 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> 
> Hello, again,
> 
> David Gray <deg at davidegray.com> wrote:
>> dave at dave-VirtualBox:~/.gnupg/crls.d$ dirmngr --debug-all --fetch-crl http://crl.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crl
> 
> Reading the code of dirmngr, I think that --fetch-crl (or dirmngr-client
> --load-crl) doesn't work well for a CRL which is not signed by system CA
> directly.  When dirmngr doesn't know the issuer, it inquires back to the
> client, and it fails as:
> 
>> dirmngr[3184.0]: DBG: find_cert_bysubject: certificate not returned by caller - doing lookup
>> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
>> dirmngr[3184.0]: CRL issuer certificate {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
>> dirmngr[3184.0]: crl_parse_insert failed: Missing certificate
> 
> When it is gpgsm which asks dirmngr to validate a certificate, I think
> it works.
> 
> I think that you once successfully did that on this box:
> 
>> dave at dave-VirtualBox:~/.gnupg/crls.d$ gpgsm --debug-all --list-keys --with-validation
> 
> And the CRL is cached.  Thus,
> 
>> gpgsm: DBG: chan_6 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C
> 
> This is gpgsm asking if your X.509 client certificate is valid or not.
> 
>> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> 
> Here, I think that the CRL for your X.509 client certificate is cached
> and checked.  dirmngr does not ask about anything about your X.509
> client certificate or its issuer.
> 
> dirmngr inquires back to gpgsm if the root issuer is trusted.
> 
>    CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
>    fingerprint=02FAF3E291435468607857694DF5E45B68851868
> 
> then, gpgsm asks to gpg-agent.
> 
>> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_7 <- OK
> 
> It is trusted.  Then, gpgsm replies back to dirmngr.
> 
>> gpgsm: DBG: chan_6 -> D 1
>> gpgsm: DBG: chan_6 -> END
> 
> It's trusted.
> 
>> gpgsm: DBG: chan_6 <- OK
> 
> Then, dirmngr answers OK for the validation of your X.509 client certificate.
> 
>> gpgsm: DBG: chan_6 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
> 
> This is gpgsm asking if the intermediate certificate of following is
> valid or not:
> 
>    CN=COMODO SHA-256 Client Authentication and Secure Email CA,O=COMODO CA Limited,
>    L=Salford, ST=Greater Manchester, C=GB
>    fingerprint=59B825FC08860B04B392CC25FEC48C760753B689
> 
>> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_7 <- OK
>> gpgsm: DBG: chan_6 -> D 1
>> gpgsm: DBG: chan_6 -> END
>> gpgsm: DBG: chan_6 <- OK
> 
> Similar interactions between gpg-agent<->gpgsm<->dirmngr.
> 
>> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_7 <- OK
> 
> I don't know the exact reason, but gpgsm again asks gpg-agent.
> 
> And gpgsm shows your X.509 client certificate:
> 
>>           ID: 0x2F5900E9
>>          S/N: 3FAADAD7DD3F946B114321153B76F88C
>>       Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
>>      Subject: /EMail=user at domain.com
>>          aka: user at domain.com
>>     validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59
>>     key type: 2048 bit RSA
>>    key usage: digitalSignature keyEncipherment
>> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested)
>>     policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N:
>>  fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9
>>  [Note: non-critical certificate policy not allowed]
>>  [Note: non-critical certificate policy not allowed]
>>  [validation model used: shell]
>>  [certificate is good]
> 
> On the other hand, on your Windows...
> 
>> C:\Users\dave\Downloads>gpgsm --list-keys --with-validation --debug-all
> [...]
>> gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
>> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> [...]
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
>> gpgsm: DBG: chan_0x000001c0 -> D 1
>> gpgsm: DBG: chan_0x000001c0 -> END
>> gpgsm: DBG: chan_0x000001c0 <- OK
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
> [...]
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
> [...]
>> gpgsm: DBG: chan_0x000001c0 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C
>> gpgsm: DBG: chan_0x000001c0 <- INQUIRE SENDCERT
>> gpgsm: DBG: chan_000001C0 -> [ 44 20 30 82 05 3b 30 82 04 23 a0 03 02 01 02 02 ...(982 byte(s) skipped) ]
>> gpgsm: DBG: chan_000001C0 -> [ 44 20 74 69 6f 6e 61 6e 64 53 65 63 75 72 65 45 ...(361 byte(s) skipped) ]
>> gpgsm: DBG: chan_0x000001c0 -> END
> 
> Here, gpgsm asking if your X.509 client certificate is valid or not.
> And then, dirmngr inquires back to gpgsm about the certificate.
> 
> Then gpgsm sends it to dirmngr.
> 
>> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
>> gpgsm: DBG: chan_0x000001c0 -> D 1
>> gpgsm: DBG: chan_0x000001c0 -> END
> 
> And then, dirmngr inquires back to gpgsm if the root issuer is trusted.
> 
>    CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
>    fingerprint=02FAF3E291435468607857694DF5E45B68851868
> 
> then, gpgsm asks to gpg-agent.  It is trusted.  Then, gpgsm replies back to dirmngr.
> 
>> gpgsm: DBG: chan_0x000001c0 <- ERR 167772255 No CRL known <Dirmngr>
> 
> But, dirmngr says no CRL known for your X.509 client certificate.
> 
> I don't know what's going on here.  You can enable debug option of
> dirmngr (debug-level, log-file, debug-all) in your dirmngr.conf.
> 
> 
> [...]
>> gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
>> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
>> gpgsm: DBG: chan_0x000001c0 -> D 1
>> gpgsm: DBG: chan_0x000001c0 -> END
>> gpgsm: DBG: chan_0x000001c0 <- OK
>> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
>> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax
>> gpgsm: DBG: chan_0x000001e8 <- OK
> 
> This is the interaction for the intermediate certificate.  Nothing wrong here.
> 
>>           ID: 0x2F5900E9
>>        S/N: 3FAADAD7DD3F946B114321153B76F88C
>>       Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
>>      Subject: /EMail=user at domain.com
>>          aka: user at domain.com
>>     validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59
>>     key type: 2048 bit RSA
>>    key usage: digitalSignature keyEncipherment
>> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested)
>>     policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N:
>>  fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9
>>  [Note: non-critical certificate policy not allowed]
>>  [no CRL found for certificate]
>>  [Note: non-critical certificate policy not allowed]
>>  [validation model used: shell]
>>  [certificate is bad: No CRL known]
> 
> You can check your X.509 client certificate by
> 
>    $ gpgsm --verbose --dump-cert 0x2F5900E9
> 
> to see its CRL or more information.
> -- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2368 bytes
Desc: not available
URL: </pipermail/attachments/20170222/9d129e02/attachment.bin>


More information about the Gnupg-users mailing list