1

I have a self-signed certificate that was created using makecert on Windows. Now this certificate has to be used by a new application; this new app is using openssl in the background for certificate validation. The problem I have is that if I type this command:

openssl.exe verify sts-token-signing.pem

I have this result:

error 20 at 0 depth lookup:unable to get local issuer certificate

Whereas the result I am expecting is this one (I get this answer with another makecert certificate):

error 18 at 0 depth lookup:self signed certificate
OK

If I print the details of the cert using openssl.exe x509 -text -noout -in sts-token-signing.pem, I have:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            40:c1:c8:1e:65:b0:25:8d:4a:86:a1:4a:dc:0a:ea:5b
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=sts.example.com - Token Signing
        Validity
            Not Before: Feb  2 08:24:46 2015 GMT
            Not After : Jan 30 08:24:46 2020 GMT
        Subject: CN=sts.example.com - Token Signing
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    hexdata
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                65:0E:B9:FB:1D:A6:EF:37:94:BA:43:4D:55:D2:9D:6D:1C:C6:87:ED
            X509v3 Key Usage: critical
                Key Encipherment
    Signature Algorithm: sha1WithRSAEncryption
         hexdata

As you can see, the "Issuer" and "Subject" are the same. So it is self-signed. My guess is that some of the extensions are not valid from openssl point of view.

  1. Does anyone know how I could make openssl accept this certificate?

  2. Another idea, is it possible to remove some X509v3 extensions from the PEM file if I don't have the private key?

(I don't care about the extensions actually, all I need is to give a PEM file to an application, so this app can validate signatures based on the public key contained in the file)

|improve this question
  • That KeyUsage is definitely wrong for 'token signing' and ExtKeyUsage probably is -- but OpenSSL doesn't check these (for leaf) by default; commandline verify does only if you specify a purpose, and for an application it depends on the code. Longshot but worth a try: display with openssl asn1parse <pemfile and make sure the subject and issuer not only display the same but are encoded as the same ASN.1 type(s). – dave_thompson_085 Jan 26 '18 at 9:49
  • @dave_thompson_085 Both of them are of type "UTF8STRING". So I guess they are identical (I dont find a way to display these UTF8 strings in hex, openssl displays the actual character). But ok, I understand now that the KeyUsage is wrong. – Matthieu Jan 26 '18 at 16:30
2

If you're just using the cert for the public key, why bother calling validate? If you want to know that the file isn't corrupt, it isn't... or you would have gotten a much different error.

The validate algorithm is upset that you have a Key Usage extension which does not specify the certificate signing usage. In future revisions of the certificate, either add the certificate signing usage, or omit the Key Usage extension altogether.

If you were to edit the certificate to remove the extension then the signature wouldn't work for the public key, so the certificate would be self-issued, but not self-signed... which means there must be a parent certificate somewhere. So it doesn't really solve any problems for you. The effective answer is "no, you need the private key to re-issue a self-signed cert".

Experiment data:

ss_badku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2818056532535039313 (0x271bbf7c52b85551)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
            X509v3 Key Usage: critical
                Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
         95:49:6c:90:bb:87:92:54:ba:c9:1b:a6:98:7a:9e:29:15:b7:
         b0:c7:75:fa:e2:66:4c:79:74:71:69:e3:17:cf:dc:6f:90:a2:
         f4:f1:7f:51:cd:7c:14:ed:6f:7d:32:55:55:41:8d:91:d2:31:
         2d:76:b0:6c:3f:76:6e:41:40:61
-----BEGIN CERTIFICATE-----
MIIBfDCCASagAwIBAgIIJxu/fFK4VVEwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
AxMKRXhwZXJpbWVudDAeFw0xODAxMjYxNTAwNTVaFw0yODAxMjYxNjAwNTVaMBUx
EzARBgNVBAMTCkV4cGVyaW1lbnQwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAm2pu
NzmEVwRTNGQ+c/B2wZ0E5YE3AsxtAvddODousF9bQq1nUsyIlUaSULcwa8XGNuOM
SCRqHFrdkholRMhhEwIDAQABo1owWDAnBgNVHSUEIDAeBggrBgEFBQcDAQYIKwYB
BQUHAwIGCCsGAQUFBwMDMB0GA1UdDgQWBBRfWYOO+9MTvXBf6TjDo9lJ9vS9MTAO
BgNVHQ8BAf8EBAMCBSAwDQYJKoZIhvcNAQELBQADQQCVSWyQu4eSVLrJG6aYep4p
Fbewx3X64mZMeXRxaeMXz9xvkKL08X9RzXwU7W99MlVVQY2R0jEtdrBsP3ZuQUBh
-----END CERTIFICATE-----

ss_noku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 10026821066004793515 (0x8b266ca2999e88ab)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
    Signature Algorithm: sha256WithRSAEncryption
         72:a1:23:a0:00:c1:e0:dc:9a:11:21:4b:57:aa:42:49:c5:ae:
         05:e7:97:43:71:75:2d:33:b2:9f:96:4c:45:4d:80:91:51:5a:
         6f:bb:f3:03:67:10:f9:ac:f8:d5:00:b5:4b:85:10:2e:d7:45:
         d2:8f:e1:2e:0b:98:dd:e3:3e:fb
-----BEGIN CERTIFICATE-----
MIIBbTCCARegAwIBAgIJAIsmbKKZnoirMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNV
BAMTCkV4cGVyaW1lbnQwHhcNMTgwMTI2MTUwMDU1WhcNMjgwMTI2MTYwMDU1WjAV
MRMwEQYDVQQDEwpFeHBlcmltZW50MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJtq
bjc5hFcEUzRkPnPwdsGdBOWBNwLMbQL3XTg6LrBfW0KtZ1LMiJVGklC3MGvFxjbj
jEgkahxa3ZIaJUTIYRMCAwEAAaNKMEgwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsG
AQUFBwMCBggrBgEFBQcDAzAdBgNVHQ4EFgQUX1mDjvvTE71wX+k4w6PZSfb0vTEw
DQYJKoZIhvcNAQELBQADQQByoSOgAMHg3JoRIUtXqkJJxa4F55dDcXUtM7KflkxF
TYCRUVpvu/MDZxD5rPjVALVLhRAu10XSj+EuC5jd4z77
-----END CERTIFICATE-----

ss_ku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 14221161353214574683 (0xc55bb6e75fde405b)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
            X509v3 Key Usage: critical
                Key Encipherment, Certificate Sign
    Signature Algorithm: sha256WithRSAEncryption
         5e:eb:47:69:b0:65:c2:c1:d8:ee:85:0d:66:ae:76:96:ab:47:
         bc:dd:ea:2e:c8:f6:bf:1d:c2:1f:d3:e6:f0:ca:1a:80:5d:00:
         7c:a5:cd:2b:0d:b9:b1:31:84:f9:ed:75:72:5a:31:82:ef:c3:
         9e:7e:16:b3:68:aa:89:8a:80:52
-----BEGIN CERTIFICATE-----
MIIBfTCCASegAwIBAgIJAMVbtudf3kBbMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNV
BAMTCkV4cGVyaW1lbnQwHhcNMTgwMTI2MTUwMDU1WhcNMjgwMTI2MTYwMDU1WjAV
MRMwEQYDVQQDEwpFeHBlcmltZW50MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJtq
bjc5hFcEUzRkPnPwdsGdBOWBNwLMbQL3XTg6LrBfW0KtZ1LMiJVGklC3MGvFxjbj
jEgkahxa3ZIaJUTIYRMCAwEAAaNaMFgwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsG
AQUFBwMCBggrBgEFBQcDAzAdBgNVHQ4EFgQUX1mDjvvTE71wX+k4w6PZSfb0vTEw
DgYDVR0PAQH/BAQDAgIkMA0GCSqGSIb3DQEBCwUAA0EAXutHabBlwsHY7oUNZq52
lqtHvN3qLsj2vx3CH9Pm8MoagF0AfKXNKw25sTGE+e11cloxgu/Dnn4Ws2iqiYqA
Ug==
-----END CERTIFICATE-----

And the execution:

$ openssl verify ss_badku.cer ss_noku.cer ss_ku.cer
ss_badku.cer: CN = Experiment
error 20 at 0 depth lookup:unable to get local issuer certificate
ss_noku.cer: CN = Experiment
error 18 at 0 depth lookup:self signed certificate
OK
ss_ku.cer: CN = Experiment
error 18 at 0 depth lookup:self signed certificate
OK
|improve this answer
  • "why bother calling validate" -> the 3rd party app we are using is calling validate... I'll write to their support for a way to disable this "feature". Thanks for your explanation! – Matthieu Jan 26 '18 at 8:02
  • 1
    OpenSSL validation doesn't require AKI, although if AKI and SKI are present on child and parent respectively they must match. But in this case the cert is supposed to be seflsigned and there is no parent. – dave_thompson_085 Jan 26 '18 at 9:45
  • @dave_thompson_085 You're right, the check is if both SKID and AKID exist they must match, not that SKID must resolve. Looking at X509_check_issued, it seems that the problem is that the KeyUsage doesn't permit cert signing. (subject->issuer matches issuer->subject, SKID matches AKID if applicable, and issuer has no KeyUsage or KeyUsage permits cert signing). I'll do some experiments and then update the answer. – bartonjs Jan 26 '18 at 14:21
  • 1
    Bad KeyUsage it is. Updated answer. – bartonjs Jan 26 '18 at 16:06
  • @bartonjs Great experiment, that explains my problem:) – Matthieu Jan 26 '18 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.