Could you help me on a strange behaviour trying to sign or encrypt a file: When Itry to sign a file with a particular S/Mime cert it shows an error saying that has no private key. I tried with GPA and with Kleo. Other certs work OK. The cert works ok sending email from Outlook 2013 with native support for s/mime. I don’t know how to try with gpgsm in command mode. I tried to delete and reimport the certificate and same happens. One curious think: No new file appears in private-keys-v1.d directory. It seems that no deletion of old private key. Is there any way to verify the consistency of pubring and private keys dir? (I stopped all services after deleting the cert to delete cache).
Thks in advance.
strange, it shows “no public key” and not no private key. Does it show in Kleopatra if you select “My certificates” in the drop down?
An Idea of me would be that you are missing the certificate chain (Root and intermediate Certificates) for this key so that maybe GPGSM complains about a missing public key of the parent certificate.
There is no real way to check for the consistency of the public key / vs private key directory. For each public key GnuPG looks into the private keys directory to find a matching private key. There is no way to do it the other way around.
On the Command line “gpgsm -K” shows all public/private key pairs you have and they are written in bold in Kleopatra.
gpgsm --with-validation -K
might show you more info if all these pairs are valid.
echo Hello | gpgsm -sau “your-keyid”
Let’s you test signing on the command line.
I’ll send the cert and the chain of certs to your email because it’s an official certificate issued by a Spanish gov, agency and available for every Spanish citizen. Using cmd also says error in public key. But I see it using XCA (an open ssl front end) and says ok. It seems an issue with gpgsm… Or it’s unable to verify the validity (only available using OCSP).
I Did further debugging and I attached you the full chain of certificates. Now I add the OCSP signing certificate. Some things:
1.- Disabling CRL’s check doesn’t solve the trouble.
2.- Due that CRL’s are unavailable the validity of OCSP signing certificate can’t be verified.
Any way to make a cert trusty?
Any way to avoid the verification of a particular cert (OCSP or end user cert)?
At this state I can’t use my end user cert to encrypt nor sign files/emails.
Thks for your time and help.
OCSP_AC_FNMT_Usuarios.crt (1.37 KB)
I do not really understand why disabling CRL checks does not solve it, if you have not explicitly enabled OCSP checks this should work. It sounds like OCSP checks are still enabled.
There is sadly no way to disable CRL/OCSP checks only for a specific cert chain. It’s all or nothing.
The only one thing I can think for would be to configure the OCSP responder certificate explicitly in Kleopatra → S/MIME Validation → Online Certificate Validation.
But I’m not sure if you would then also need to configure the OCSP responder explicity. And that would cause it to be used for all your certificates, so this is also not a good option. That option is mostly intended for Organizations that use a single OCSP service.
You are right: OCSP were still enabled. I was trying to use OCSP without CRL’s verification. Is there any way to do that?
Disabling CRL’s and OCSP works fine.
But no public key found when is no validation of cert were a confusing msg.
Thanks for your time.
Josep Yes. The error is confusing. It’s just one of these errors we don’t usually see so the code branches that handle this stuff are not so good and well tested.
Using OCSP without CRL’s is possible (enable ocsp and disable CRL) but from your description it sounds like both OCSP and CRL checks do not work for this certificate. :-/
Btw. I commented in a ticket of us about your issue https://dev.gnupg.org/T4118 I think that we should add a way to mark a root certificate as “disable online verification for this one certificate”.
Pls notify me how can I help you in this task. A little background info:
The CA is: https://www.sede.fnmt.gob.es/en/inicio
There are a lot of info w/o translation there!
The hierarchy is:
AC RAIZ FNMT-RTM ->AC FNMT USUARIOS → MY CERT
- Servidor OCSP AC FNMT Usuarios
I did some frame captures with Wireshark, and the response of ocsp query is Succesfull for both certs (end user and signing ocsp cert). The trouble starts verifying ocsp signature. The intermediate AC’s work fine because they supply CRL’s. No CRL’s for end user nor OCSP signing cert.
In acrobat reader the signature verification works ok using this user cert. Also in native s/mime mode in Outlook signing/encrypting.
I send you a pdf file signed and encripted. Acrobat verifies as signature OK.
Also I send you another group of certs from different AC that also give same error.
I think that something fails in GNUPG dirmngr/gpgsm verifying validity. Could be related with rfc 6960 and extension id-pkix-ocsp-nocheck?
A possible solution could be add a third state of a certificate: Certified/no certified/user certified. Your solution could be interesting but I’m not shure that solves the trouble, just bypasses it. I hope that these files help you.
And I have one more question:
Looking on GNUPG user’s manual I see a gpgsm option named --validation-model. Could you give more details? What are this models and how they work?
I apologize for this long trouble. I’m just trying to debug something that seems a bug in ocsp verifying. Be free to tell me if I stole your time in excess.
Andre validity tests.tar.gpg (151 KB)
You are not wasting my time You looking into it and trying to improve Gpg4win is appreciated, so thank you for your time.
I’ve opened https://dev.gnupg.org/T4292 for this, as this is nothing that we can fix right away and so it does not get forgotten over the holidays.
The ocsp-nocheck could indeed be a solution here if I understand the spec correctly.
Regarding Adobe and Outlook. I know that Outlook does not have a hard failure if it can’t fetch CRLs. For Adobe I do not know. But yes they probably just respect that extension and so they don’t have a problem.
Regarding --validation-model this is more of an experimental feature / was planned to do more than it currently does. I don’t know much about it but this is not a solution to your problem.
In the task Werner Koch mentioned a possible solution:
He is using:
in dirmngr.conf with FILE being in ~/.gnupg and having a list of valid responder certificates. It is one of the suggested solution from rfc6960.
Maybe this is a useful workaround for you?
Good workaround, but I’m trying w/o success. Could you ask Werner (I don’t have access for writing to this forum) what he fits in this file? S/n, keygrip, sh1hash of the certificate (with or w/o colons)?
This could be a workaround but I think that should be more automatic (ocsp certs are renewed frequently), like acrobat rdr does… Future task…
You can register on dev.gnupg.org and I can approve your account. But I’ll ask.
I think the file should contain the ocsp signer certificates themself in PEM format. Like:
I don’t know if you have seen it but the response was:
A list of SHA-1 fingerprints for the valid certificates. With our without colons.
Yes, I saw. But it doesn’t work. I tried time ago before filling the field in GUI dialog. So, I should wait for a more efficient solution. Meanwhile I deactivated searching and verifying CRLs so not verifying validity.
But I notify you some bug (I think):
When the field of OCSP sign is filled and applied, after that it can’t be deleted nor modified to fill a filename of the signatures file. I think that a delete mark is missing and a folder icon could be useful to select a signatures file. I deleted the contents opening and editing dirmngr.conf. I attach a screen capture of this field.
ocsp sign.bmp (1.13 MB)
Sad to hear that it did not work for you.
Yes. It should be deletable.
Honestly, I was not even aware that you could put a filename in that parameter