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