Unable to encrypt with imported X.509 certificates [RESOLVED]

Hi Suzo,
setting up X509 encryption can be a bit cumbersome.

A delay can happen if the certificate revocation information is slow in coming.
Please try the command line (and verbose) and debugging infos there.
The command for X509 is gpgsm.

https://wiki.gnupg.org/TroubleShooting

It can be an idea to switch off certificate revocation list checking to see if that is the cause of trouble. (Don’t forget to turn it on again. :wink: ).

Best Regards,
Bernhard

I would also suggest to disable CRL checks for now. (Kleopatra->Settings->S/MIME Validation->Never consult a CRL).

But, Internal Error points to a Problem in our Software. We should at least check it out and see if we can reproduce the problem. I’ve opened a task in our ticketing system for this: https://dev.gnupg.org/T3907

Thnk for your replies,

There were many certificates in my installation. A mixture of OpenPGP and S/MIME. They were there essentially for exploration purposes. I explore this new technology. Now I know that i want to rely exclusively on X.509 certificates. They’re safer from my point of view. My first attempt was to import the root certificat (.der) then my personal certificat (.p12). I erased them all. And start with a fresh directory %APPDATA%\gnupg. Then, i only imported my personal certificat. The root certificat appeared because of yout soft not because of an import. From there i was able to encrypt/decrypt. The only thing that annoy me is the ‘infinite’ delay. When i click ‘do not consult revocation list’. The result is almost instantaneous. But when it is unchecked, it takes so long! What i don’t understand now. Why checking the revocation list, if my certificat is valid ?

Let me amend my last post.

With a check at ‘do not consult revocation list’ encryption/decryption works fine. The encryption took around 1.5 hourS with an uncheck mark and ended with a failure message ‘Error with loading of audit journal - No known CRL’. Does it try to write to Windows Observer Event Journal ? Because there is no trace in that journal.

With this new message, do you still need an output of command ‘gpgsm’ ?

Does the massage says that the CRL cannot be found or my certificat is not listed inside such a list ?

I managed to extract an ASN1 portion of myCertificate.cer (see unloaded picture). Both informations about OCSP and CRL are available. Wheter the list is not found or my certificat is not recognize valid, there is an error.

I found from this web site
http://docs.acquia.com/article/verifying-validity-ssl-certificate
a command to verify the validity
openssl verify -CAfile certificate-chain.crt certificate.crt

It looks simple to me to check for validity. All financial transactions over the web are fast. Very very long delay for X.509 certificat checking is unacceptable. I guess you adhere yourself to this evidence.

bug 2018-04-13 delay.jpg

Hi Suzo,

your analysis about the difficulties with revocation information and X509 is spot on, we also believe that this is not a very practical way. However many X509 profiles are defined in a way that revocation information is important and mandatory. The idea is that if your certificate gets lost or somehow compromised, there is a way to find out. A reasonable security system of course has to take measured against this.

That the cacert CRL is too large and long is a problem specifically with cacert. I don’t know why they do that. Other certificate authorities run their revocation lists or ocsp infos differently.

Once setup X509 can provide a nice user experience. However it is hard to setup and maintain and needs experienced system administrators. Have a look at the writings
of Peter Gutmann to see some of the problems X509 has in store: https://www.cs.auckland.ac.nz/~pgut001/

Best Regards,
Bernhard

Hi Bernhard,

Many questions still unanswered and would greatly help to understand.

Does it try to write to Windows Observer Event Journal ?
Do you still need an output of command ‘gpgsm’ ?
Does the massage says that the CRL cannot be found or my certificat is not listed inside such a list ?
Wheter the list is not found or my certificat is not recognize valid, there is an error. Why ?

Hi Suzo,

let me try to give you answers where I can:

Does it try to write to Windows Observer Event Journal ?

I don’t think any component does, but I have not verified this.

Do you still need an output of command ‘gpgsm’ ?

Probably not, though it may help if you add some of this to ⚓ T390 GnuPG in batch mode fails to sign keys which expire
as an extra information.

Does the massage says that the CRL cannot be found
or my certificat is not listed inside such a list ?

The diagnosis message indicates that something is wrong and is not specific enough.
Using the test to temporarily disable revocation checks let us assume that the problem
is somewhere with the crl handling and the specific crl in question.

If GnuPG cannot get the list, it also cannot verify that your certification is not in there.

Wheter the list is not found or my certificat is not recognize valid, there is an error. Why ?

Because most common X509 protection profiles have it as a hard requirement
that revocation information have been checked (for not listing a cert) before they assume
a cert to be valid and usable.

The error message could be more detailed to tell you about it.

Best Regards,
Bernhard

Hi Bernhard,

The bug repport (GnuPG in batch mode fails to sign keys which expire) https://dev.gnupg.org/T390 is maked as ‘Closed, Resolved’. So there is nothing to add there. Nothing is in commun with this thread. Batch mode (Interactive). Signing (Encrypting). Key expired (Valid certificat). Are you drunk?

But the above link made me discover this one. (Internal error when encrypting to cacert certificate) https://dev.gnupg.org/T3907
I did the same. And the download took 46 minutes. That explains in part the long delay. One could conclude that the downloaded CRL is exhausly checked. That would explain the gap between 46 minutes and 90 minutes. Here 90 minutes (1.5 hour) is the total time for actual bug. But the most amazing part concerns the final bug message. Let me know what you think about following pseudo-code.

if (searched_certificat not in crl_list)
then print (No known CRL)
else print (Encrytion impossible due revoked certificat)

Please continue to use the longest path which is checking the CRL list. Checking validity via OCSP could be a disaster. I mean this could conclude to a positive result in a very fast time.

Hi Suzo,
sorry for the copy and paste error in the URL to the report.
(Andre had given that URL earlier.)

Usually a cert should not be in the CRL to be valid.
This keeps CRL size reasonable.

Best Regards,
Bernhard

Hi Bernhard,

This keeps CRL size reasonable.
I don’t know if 8MB is reasonable. Waiting more than an hour is not reasonable. My internet connection can download that size in less than 2 minutes. And that amount of time is still unacceptable. That is NOT the point.

Developers of this project simply don’t use the right technology for such a verification. 1) The first step is to check the validity between the certificat and the signing authority. 2) The second step is to check the expiration date. 3) And third and final step is to check if the certificat has not been revoked. We all agree on those. Where we don’t agree is on the meaning of step #3. Developers DON’T have to do this checking themselves. They should use an existing service provided by all signing authorities. The demander of such a service send only one request and receive an answer in less than a second. That service is called OCSP.

See Uploaded picture for the 3 steps. For the third step, the parameter -issuer contains the certificate chain and the parameter -CAfile contains the root certificate of signing authority.

I let you transmit that information to the Developer Team. You owe me that for the bad cut and paste.

Best Regards,
Suzo

bug 2018-04-13 ocsp.jpg

Hi Suzo,

as you have seen the download speed of the cacert crl is slow and not helpful.
This is out of our control, it is an issue with how cacert serves this.

The issue with OCSP is that it leaks more information those single requests.
And yes, GnuPG implements OCSP, check into the documentation (–allow-ocsp).

Overal both CRLs and OCSP have their drawbacks in real-live (see the writings of Peter Gutmann for mentioning some of these, if you are deeply interested.)

Best Regards,
Bernhard

Thanks to the reports by you and others here in the Forum I did some testing on Windows. While it worked for small CRL’s like our test CRLs / CA’s we found an big error in our software with CRLs on Windows.

https://dev.gnupg.org/T3923

Will be fixed soon. We’ll probably do a new release early next week.

Hi Bernhard, Hi Andre,

Let me sum up. When a user (company or individual) have i high volume of transactions, it faster to download one file (a CRL list) an do all the check up from there. If a user have few or one transaction, it is faster to use the OCSP service.

Both of these solutions (encryption with x.509 certificat checking) do not work with Gpg4Win/Kleopatra.
In one case the list is not correctly handled/verified and come to a wrong conclusion. And in the other in simply refuse to do the job.

For the first solution. Andre saw it right.

… we found an big error in our software …
Will be fixed soon.
I’m glad to read that! There is engagement to final users/commnunity!

For the second solution. Bernhard said:

And yes, GnuPG implements OCSP …
It is NOT implemented. The message in this uploaded picture said ‘Not taken in charge’.

For the majority of us. We don’t have mass treatment to do. We have one or few encryptions to do. We would be better disserved by the OSCP service. I had clearly demonstrate that the check up with OCSP works just fine in previous uploaded picture (bug 2018-04-13 ocsp.jpg). I hope you will implement it (OCSP) in a near future. Many hot regions on this planet need cheap/fast/secured transmissions. And this is the exact purpose where this software can make a difference.

bug 2018-04-13 Denial.jpg

Hi Suzo,

thanks for helping to frame the CRL problem on windows that affected some long crls.

About OCSP: The implementation in GnuPG is there, as always, we cannot exclude defects or other problems by special certs or CAs. The next step is to get a reproducable case that shows problems together with diagnostic information.

Best Regards,
Bernhard

Hi Bernhard,

… or other problems by special certs or CAs. The next step is to get a reproducable case …
Don’t have a special cert. To reproduce the case; get a free cert from CACert.org and try to encrypt with setup OSCP enabled.
I can try to help if you have difficulties with registration at CACert.org but it’s quite simple.
I already uploaded the buggy screen (bug 2018-04-13 Denial.jpg).
Tell me about good or bad issue with this case reproduction.

Hi Suzo,

we will put this on our stack.

Best Regards,
Bernhard

I tried it out and the “Not Supported” comes when “allow-ocsp” is not set in the dirmngr.conf
You should be able to set this in the Network tab of the configuration in Kleopatra.
Alternatively in %APPDATA%\gnupg\dirmngr.conf

I opened a task to improve that: https://dev.gnupg.org/T3933

With this CACert OCSP works for me. But, I get “configuration error” when I try to encrypt to a certificate that has no OCSP Responder value. We are working on a fix for this right now.

cacert-ocsp.png

Hi Bernhard, Hi Andre,

I really thought that OCSP wasn’t implemented due to message “Not Supported”. The message would give a better clue with “OCSP not enabled in setting(s)”. The task: https://dev.gnupg.org/T3933 is a good initiative.

Now certificat checking + file signing and encrytpting, all take around 6 seconds. Much much better! From my part this thread can be mark as RESLOVED. But don’t know how to edit the original title of this post.

Thank you guys for all your support!

p.s. The following isn’t related with the main topic of this post. It’s more a feature request. When i leave kleopatra.exe, i would also like to have dirmngr.exe + gpg-agent.exe daemons closed. Old computer that needs all resources as free as possible.

Have a good day!

bug 2018-04-13 resolved.jpg

RESOLVED sorry

Hi Suzo,

great to hear that it is working for you now!

Thanks for all the feedback!
Bernhard