Re: Problems with cert validation via CRL
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 wrote:
>
> Hello, again,
>
> David Gray wrote:
>> dave@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@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=u...@domain.com
>> aka: u...@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_0x00
RE: Problems with cert validation via CRL
You were correct, Peter. I haven't had a chance to verify on Ubuntu yet, but
on Windows the following steps did the trick:
- there was no 'trusted-certs' directory in my existing home directory
(C:\users\dave\appdata\Roaming\gnupg\), so I created one. I also went ahead
and created a 'logs' directory.
- I added the line "log-file
C:\Users\dave\AppData\Roaming\gnupg\logs\dirmngrlog.txt" to my dirmngr.conf
file to capture what I wanted
- I saved a copy of the root cert with fingerprint
02FAF3E291435468607857694DF5E45B68851868 to a DER-encoded file with .crt
extension to the 'trusted-certs' directory.
- I executed the 'gpgsm --list-keys --with-validation --debug-all' command,
and all keys were shown to be good.
I've attached the debug output from the command as well as the dirmngrlog.txt
file that was generated in case it is of interest. (As an aside, you may
notice that I've installed version 2.1.18 since the last output was provided).
I don't fully understand everything that is shown in these files, but it sure
seems to me like you were exactly right - dirmngr did not know to trust that
root cert, so it couldn't verify that the CRL was signed by a trustworthy
party. Once I told dirmngr that the root cert could be trusted, it could
verify the CRL. I've since been able to encrypt data using this key, so
things are looking good.
I can't thank you enough - this has been extremely helpful.
Thanks!
Dave
-Original Message-
From: Peter Lebbing [mailto:pe...@digitalbrains.com]
Sent: Tuesday, February 21, 2017 10:13 AM
To: David Gray ; NIIBE Yutaka
Cc: gnupg-users@gnupg.org
Subject: Re: Problems with cert validation via CRL
On 21/02/17 13:20, David Gray wrote:
> I'm no expert, but when I look at the debug info (attached to original
> email), it appears that gpgsm is able to get the crl that my cert
> points to but it may be having trouble parsing it.
Reading that part made me think it couldn't find the issuer of the CRL:
> dirmngr[3184.0]: error fetching certificate by subject: Configuration
> error
> dirmngr[3184.0]: CRL issuer certificate
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
When I fetch the CRL we're talking about, OpenSSL tells me about it:
> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
> Last Update: Feb 20 16:07:34 2017 GMT
> Next Update: Feb 24 16:07:34 2017 GMT
> CRL extensions:
> X509v3 Authority Key Identifier:
>
> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>
> X509v3 CRL Number:
> 822
The issuer is the certificate that gpgsm knows about:
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network,
> CN=AddTrust External CA Root
> Validity
> Not Before: Dec 22 00:00:00 2014 GMT
> Not After : May 30 10:48:38 2020 GMT
> Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA
> Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA [...]
> X509v3 extensions:
> X509v3 Authority Key Identifier:
>
> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
>
> X509v3 Subject Key Identifier:
>
> 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
> [...]
> SHA1
> Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:8
> 9
I suspect that even though gpgsm knows about it, dirmngr might not, hence the
failing CRL verification. I think you need to feed the certificate to dirmngr
as well.
Whether this is actually the reason you're having problems, I don't know.
HTH,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
C:\Users\dave>gpgsm --list-keys --with-validation --debug-all
gpgsm: reading options from 'C:\Users\dave\AppData\Roaming\gnupg\gpgsm.conf'
gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing ipc
C:\Users\dave\AppData\Roaming\gnupg\pubring.kbx
---
ID: 0x0753B689
S/N: 00E023CB1512835389AD616E7A54676B21
Issuer: /CN=AddTrust External CA Root/OU=AddTrust External TTP
Network/O=AddTrust AB/C=SE
Subject: /CN=COMODO SHA-
Re: Problems with cert validation via CRL
Hello, again,
David Gray wrote:
> dave@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@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=u...@domain.com
> aka: u...@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_0x01c0 -> ISVALID
> 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
> gpgsm: DBG: chan_0x01c0 <- INQUIRE ISTRUSTED
> 02FAF3E291435468607857694DF5E45B68851868
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
> gpgsm: DBG: chan_0x01c0 -> D 1
> gpgsm: DBG: chan_0x01c0 -> END
> gpgsm: DBG: chan_0x01c0 <- OK
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01c0 -> ISVALID
> 685A02B9E2BD4B5EE1FA517
Re: Problems with cert validation via CRL
Thanks, Peter!
According to the documentation the trusted certainty need to be in a folder
named "trusted-certs" in the home directory. I don't believe I've copied them
there manually, so if it hasn't happened automatically that could very well be
the issue. I'm at work but once I get home I'll check it out and report back.
Really appreciate the help,
Dave
Sent from my iPhone
> On Feb 21, 2017, at 10:13 AM, Peter Lebbing wrote:
>
>> On 21/02/17 13:20, David Gray wrote:
>> I'm no expert, but when I look at the debug info (attached to
>> original email), it appears that gpgsm is able to get the crl that my
>> cert points to but it may be having trouble parsing it.
>
> Reading that part made me think it couldn't find the issuer of the CRL:
>
>> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
>> dirmngr[3184.0]: CRL issuer certificate
>> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
>
> When I fetch the CRL we're talking about, OpenSSL tells me about it:
>
>> Certificate Revocation List (CRL):
>>Version 2 (0x1)
>>Signature Algorithm: sha256WithRSAEncryption
>>Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
>> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
>>Last Update: Feb 20 16:07:34 2017 GMT
>>Next Update: Feb 24 16:07:34 2017 GMT
>>CRL extensions:
>>X509v3 Authority Key Identifier:
>>
>> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>>
>>X509v3 CRL Number:
>>822
>
> The issuer is the certificate that gpgsm knows about:
>
>> Certificate:
>>Data:
>>Version: 3 (0x2)
>>Serial Number:
>>e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
>>Signature Algorithm: sha256WithRSAEncryption
>>Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network,
>> CN=AddTrust External CA Root
>>Validity
>>Not Before: Dec 22 00:00:00 2014 GMT
>>Not After : May 30 10:48:38 2020 GMT
>>Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited,
>> CN=COMODO SHA-256 Client Authentication and Secure Email CA
>> [...]
>>X509v3 extensions:
>>X509v3 Authority Key Identifier:
>>
>> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
>>
>>X509v3 Subject Key Identifier:
>>92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>> [...]
>> SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89
>
> I suspect that even though gpgsm knows about it, dirmngr might not,
> hence the failing CRL verification. I think you need to feed the
> certificate to dirmngr as well.
>
> Whether this is actually the reason you're having problems, I don't know.
>
> HTH,
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problems with cert validation via CRL
On 21/02/17 13:20, David Gray wrote:
> I'm no expert, but when I look at the debug info (attached to
> original email), it appears that gpgsm is able to get the crl that my
> cert points to but it may be having trouble parsing it.
Reading that part made me think it couldn't find the issuer of the CRL:
> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
> dirmngr[3184.0]: CRL issuer certificate
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
When I fetch the CRL we're talking about, OpenSSL tells me about it:
> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
> Last Update: Feb 20 16:07:34 2017 GMT
> Next Update: Feb 24 16:07:34 2017 GMT
> CRL extensions:
> X509v3 Authority Key Identifier:
>
> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>
> X509v3 CRL Number:
> 822
The issuer is the certificate that gpgsm knows about:
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network,
> CN=AddTrust External CA Root
> Validity
> Not Before: Dec 22 00:00:00 2014 GMT
> Not After : May 30 10:48:38 2020 GMT
> Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited,
> CN=COMODO SHA-256 Client Authentication and Secure Email CA
> [...]
> X509v3 extensions:
> X509v3 Authority Key Identifier:
>
> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
>
> X509v3 Subject Key Identifier:
> 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
> [...]
> SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89
I suspect that even though gpgsm knows about it, dirmngr might not,
hence the failing CRL verification. I think you need to feed the
certificate to dirmngr as well.
Whether this is actually the reason you're having problems, I don't know.
HTH,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problems with cert validation via CRL
Thank you for your response! I do have the trustlist.txt file on both computers - it was automatically populated with the root cert by pin entry when I imported my certificate on both machines, and it includes the "relax" keyword on both computers. There are 3 cents total in my hierarchy - root, intermediate, and mine. I've added the fingerprint of the intermediate and even my own cert to trustlist.txt to see if that would make a difference, but it didn't change anything. The --disable-crl-checks option allows me to use the cert for encryption, so I'm pretty sure the problem lies with the crl option...there are two files (in addition to DIR.TXT) that have been populated in crl.d, and if I do a dirmngr--flush they get cleared out and are added back fine the next time I try to validate. The root cert does NOT include a CRL DP, so I've tried turning on the option not to require a crl on trusted carts, but that didn't make a difference. I'm no expert, but when I look at the debug info (attached to original email), it appears that gpgsm is able to get the crl that my cert points to but it may be having trouble parsing it. The file itself is large, but I don't think that's uncommon, so perhaps there is a problem with the file itself. It's been updated since I started investigating, and the problem persists, so it wasn't a transient problem. Is there a way to have gpgsm (or dirmngr?) validate that it is able to parse and interpret the CRL (or the associated .db file in crl.d) to see if that is the issue? I appreciate your help very much. Thanks, Dave Sent from my Mobile Device > On Feb 20, 2017, at 9:32 PM, NIIBE Yutaka wrote: > > Hello, > > David Gray wrote: >> At the same time, I'm curious as to why the Ubuntu installation is >> validating the certificate as 'good' while the Windows installation is not - >> is this just because the Ubuntu installation was able to successfully >> validate the certificate in the past (presumably when a previous and >> non-problematic CRL was published)? If the CA publishes an updated CRL that >> doesn't have issues, will my Windows installation be able to validate the >> certificate at that point? > > Please note that my knowledge of gpgsm and X.509 is pretty much limited. > > Do you have .gnupg/trustlist.txt on Ubuntu machine? It can be created > when you answer dialog of gpgsm by pinentry interaction. > -- smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Problems with cert validation via CRL
Hello, David Gray wrote: > At the same time, I'm curious as to why the Ubuntu installation is > validating the certificate as 'good' while the Windows installation is not - > is this just because the Ubuntu installation was able to successfully > validate the certificate in the past (presumably when a previous and > non-problematic CRL was published)? If the CA publishes an updated CRL that > doesn't have issues, will my Windows installation be able to validate the > certificate at that point? Please note that my knowledge of gpgsm and X.509 is pretty much limited. Do you have .gnupg/trustlist.txt on Ubuntu machine? It can be created when you answer dialog of gpgsm by pinentry interaction. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
