Cannot verify self-signed certificates?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Cannot verify self-signed certificates?

Blumenthal, Uri - 0553 - MITLL
It appears that openssl verify refuses to deal with self-signed certificates? Is it the expected/intended behavior? I can easily imagine circumstances when a user would be happy with a “partial” validation, i.e. with validating as much as practically possible – like consistency, correctness of the options/extensions encoding, expiration dates, etc. So if this is intended, I’d like to ask to relax this, or to at least make it possible (via an appropriate option/flag) to validate self-signed certs as far as possible.

Here’s what I get:

$ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem

test2.pem: CN = test2, C = US

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

$ openssl x509 -noout -text -inform PEM -in test2.pem

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 1 (0x1)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=test2, C=US

        Validity

            Not Before: Dec 15 19:56:58 2015 GMT

            Not After : Dec 14 19:56:58 2016 GMT

        Subject: CN=test2, C=US

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:b1:9a:8f:d8:79:41:f0:8b:26:ab:f8:3c:b3:a0:

                    af:e6:a9:31:1c:de:78:5a:18:08:d4:31:9d:9f:4a:

                    6e:53:9c:4c:e2:cf:13:09:13:71:12:62:37:b4:08:

                    88:33:ab:09:55:35:25:85:e0:eb:84:4a:8a:24:60:

                    66:9c:17:df:d1:f9:e2:67:e7:c1:6b:9f:33:83:82:

                    56:ac:98:33:0b:c5:42:bc:91:61:85:4e:42:25:4a:

                    92:fb:d9:cb:55:6d:94:7d:6b:12:46:18:24:d1:0e:

                    eb:42:17:31:4c:cd:a7:6c:9c:35:c4:32:6a:06:00:

                    f2:c2:48:aa:d0:f0:31:5d:53:29:97:49:4b:73:a4:

                    a6:8d:36:58:28:1b:65:ad:f7:99:10:17:b0:2c:5b:

                    2e:44:1c:17:2e:50:9c:80:17:ff:74:1c:d0:3c:6c:

                    58:61:f6:3b:df:5e:1d:5b:df:93:7d:9f:a4:bc:d8:

                    89:0d:db:a4:4e:7d:ac:da:6d:c5:ff:25:19:63:c6:

                    6e:23:81:f2:83:ce:bc:2d:fe:7a:77:98:49:2b:0f:

                    d7:de:b1:88:90:b7:08:09:7c:6c:a3:8e:96:60:12:

                    8e:3d:79:c6:70:44:46:a1:7b:4a:26:03:c7:20:f3:

                    d3:4c:b8:76:38:d1:13:7a:3c:d7:3b:b4:88:d0:83:

                    d7:b1

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Basic Constraints: critical

                CA:FALSE

            X509v3 Key Usage: critical

                Digital Signature, Non Repudiation

            X509v3 Extended Key Usage: 

                E-mail Protection, TLS Web Client Authentication

            X509v3 Subject Alternative Name: 

                email:[hidden email]

    Signature Algorithm: sha256WithRSAEncryption

         06:c0:93:cf:03:3e:1e:3b:c3:41:70:9f:3e:e7:12:a9:ca:af:

         77:17:c9:b1:46:4d:31:13:7d:45:91:64:6b:c1:ae:32:90:5b:

         c6:12:06:75:32:e8:c3:c4:8e:29:12:08:ab:34:5d:ce:70:80:

         29:fe:12:3d:9e:32:e6:73:32:39:09:07:2c:62:88:45:c8:cc:

         9d:97:e7:26:4c:63:ca:3f:3a:79:4c:48:04:05:50:3f:b9:4a:

         45:c6:64:8f:e5:1d:44:4d:9e:6a:41:03:d7:58:d1:a3:21:44:

         01:a5:db:62:fa:9a:fd:9c:02:22:63:8b:20:a4:a1:d8:35:b6:

         85:f9:6f:a5:7d:2c:75:f2:17:f3:d2:8e:41:57:3d:55:ef:6f:

         01:06:a7:26:d1:e3:8e:cd:b1:6e:7f:3a:57:52:76:15:f7:38:

         6d:cb:0c:ae:4e:dd:a1:fa:e6:a1:8c:09:56:b3:40:e3:0c:db:

         ad:60:ca:1d:f8:d6:d8:d5:f6:57:62:41:2b:cc:67:10:34:93:

         cb:0b:53:b9:57:fb:a0:46:46:18:a6:3e:d7:23:2b:82:ca:92:

         db:66:82:ee:c3:94:b5:4c:2a:3b:f1:9d:d1:4b:09:89:a3:2f:

         2e:18:c9:83:64:b7:6b:62:c5:42:4d:76:f5:62:6b:33:50:8c:

         e5:73:82:bf

$ cat test2.pem

-----BEGIN CERTIFICATE-----

MIIDEjCCAfqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAdMQ4wDAYDVQQDDAV0ZXN0

MjELMAkGA1UEBhMCVVMwHhcNMTUxMjE1MTk1NjU4WhcNMTYxMjE0MTk1NjU4WjAd

MQ4wDAYDVQQDDAV0ZXN0MjELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUA

A4IBDwAwggEKAoIBAQCxmo/YeUHwiyar+DyzoK/mqTEc3nhaGAjUMZ2fSm5TnEzi

zxMJE3ESYje0CIgzqwlVNSWF4OuESookYGacF9/R+eJn58FrnzODglasmDMLxUK8

kWGFTkIlSpL72ctVbZR9axJGGCTRDutCFzFMzadsnDXEMmoGAPLCSKrQ8DFdUymX

SUtzpKaNNlgoG2Wt95kQF7AsWy5EHBcuUJyAF/90HNA8bFhh9jvfXh1b35N9n6S8

2IkN26ROfazabcX/JRljxm4jgfKDzrwt/np3mEkrD9fesYiQtwgJfGyjjpZgEo49

ecZwREahe0omA8cg89NMuHY40RN6PNc7tIjQg9exAgMBAAGjXTBbMA8GA1UdEwEB

/wQFMAMBAQAwDgYDVR0PAQH/BAQDAgbAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr

BgEFBQcDAjAZBgNVHREEEjAQgQ50aWhzQGhvdXNlLmNvbTANBgkqhkiG9w0BAQsF

AAOCAQEABsCTzwM+HjvDQXCfPucSqcqvdxfJsUZNMRN9RZFka8GuMpBbxhIGdTLo

w8SOKRIIqzRdznCAKf4SPZ4y5nMyOQkHLGKIRcjMnZfnJkxjyj86eUxIBAVQP7lK

RcZkj+UdRE2eakED11jRoyFEAaXbYvqa/ZwCImOLIKSh2DW2hflvpX0sdfIX89KO

QVc9Ve9vAQanJtHjjs2xbn86V1J2Ffc4bcsMrk7dofrmoYwJVrNA4wzbrWDKHfjW

2NX2V2JBK8xnEDSTywtTuVf7oEZGGKY+1yMrgsqS22aC7sOUtUwqO/Gd0UsJiaMv

LhjJg2S3a2LFQk129WJrM1CM5XOCvw==

-----END CERTIFICATE-----

$

-- 
Regards,
Uri Blumenthal

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni
On Tue, Dec 15, 2015 at 08:04:45PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> It appears that openssl verify refuses to deal with self-signed
> certificates?

You mean the command-line utility?

    $ openssl x509 -in rootcert.pem -subject -issuer
    subject= CN = Root CA
    issuer= CN = Root CA
    -----BEGIN CERTIFICATE-----
    MIIBZDCCAQugAwIBAgIBATAKBggqhkjOPQQDAjASMRAwDgYDVQQDDAdSb290IENB
    MCAXDTE1MTIxMzIzMTMwOFoYDzMwMTUwNDE1MjMxMzA4WjASMRAwDgYDVQQDDAdS
    b290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE0dpXj9GPuGRWsNkbVla9
    1o1N29JQ4zdXESfHXgVg9B0K+Rv6+IBfgMKMAmoU1P6MMKlnO57AwFqEqoENE0G3
    bKNQME4wHQYDVR0OBBYEFOS9QF8FKoIN35iD+T19P5Cq7HI/MB8GA1UdIwQYMBaA
    FOS9QF8FKoIN35iD+T19P5Cq7HI/MAwGA1UdEwQFMAMBAf8wCgYIKoZIzj0EAwID
    RwAwRAIgaGnmqp+bTUvzCAkaWnqyww42GbDXXlKIGUaOS7km9MkCIBfxuEWGEZZv
    vBCcrtNYKWa/JfwFmOq6bHk8WNzDU3zF
    -----END CERTIFICATE-----

    $ openssl verify -CAfile rootcert.pem rootcert.pem
    rootcert.pem: OK

> Here’s what I get:
>
> $ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem
>
> test2.pem: CN = test2, C = US
>
> error 20 at 0 depth lookup:unable to get local issuer certificate

No CAfile, no trust.

And your particular certificate has:

            X509v3 Basic Constraints: critical
                CA:FALSE

which does prevent it from verifying itself.  The "CA:FALSE"
constraint is only really useful in certificates issued from a
different key.  No security benefit in setin it in self-signed
certificates.

$ openssl x509 -text -noout <<EOF
-----BEGIN CERTIFICATE-----
MIIDEjCCAfqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAdMQ4wDAYDVQQDDAV0ZXN0
MjELMAkGA1UEBhMCVVMwHhcNMTUxMjE1MTk1NjU4WhcNMTYxMjE0MTk1NjU4WjAd
MQ4wDAYDVQQDDAV0ZXN0MjELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCxmo/YeUHwiyar+DyzoK/mqTEc3nhaGAjUMZ2fSm5TnEzi
zxMJE3ESYje0CIgzqwlVNSWF4OuESookYGacF9/R+eJn58FrnzODglasmDMLxUK8
kWGFTkIlSpL72ctVbZR9axJGGCTRDutCFzFMzadsnDXEMmoGAPLCSKrQ8DFdUymX
SUtzpKaNNlgoG2Wt95kQF7AsWy5EHBcuUJyAF/90HNA8bFhh9jvfXh1b35N9n6S8
2IkN26ROfazabcX/JRljxm4jgfKDzrwt/np3mEkrD9fesYiQtwgJfGyjjpZgEo49
ecZwREahe0omA8cg89NMuHY40RN6PNc7tIjQg9exAgMBAAGjXTBbMA8GA1UdEwEB
/wQFMAMBAQAwDgYDVR0PAQH/BAQDAgbAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAZBgNVHREEEjAQgQ50aWhzQGhvdXNlLmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEABsCTzwM+HjvDQXCfPucSqcqvdxfJsUZNMRN9RZFka8GuMpBbxhIGdTLo
w8SOKRIIqzRdznCAKf4SPZ4y5nMyOQkHLGKIRcjMnZfnJkxjyj86eUxIBAVQP7lK
RcZkj+UdRE2eakED11jRoyFEAaXbYvqa/ZwCImOLIKSh2DW2hflvpX0sdfIX89KO
QVc9Ve9vAQanJtHjjs2xbn86V1J2Ffc4bcsMrk7dofrmoYwJVrNA4wzbrWDKHfjW
2NX2V2JBK8xnEDSTywtTuVf7oEZGGKY+1yMrgsqS22aC7sOUtUwqO/Gd0UsJiaMv
LhjJg2S3a2LFQk129WJrM1CM5XOCvw==
-----END CERTIFICATE-----
SAMECERT
) 3<<SAMECERT
-----BEGIN CERTIFICATE-----
MIIDEjCCAfqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAdMQ4wDAYDVQQDDAV0ZXN0
MjELMAkGA1UEBhMCVVMwHhcNMTUxMjE1MTk1NjU4WhcNMTYxMjE0MTk1NjU4WjAd
MQ4wDAYDVQQDDAV0ZXN0MjELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCxmo/YeUHwiyar+DyzoK/mqTEc3nhaGAjUMZ2fSm5TnEzi
zxMJE3ESYje0CIgzqwlVNSWF4OuESookYGacF9/R+eJn58FrnzODglasmDMLxUK8
kWGFTkIlSpL72ctVbZR9axJGGCTRDutCFzFMzadsnDXEMmoGAPLCSKrQ8DFdUymX
SUtzpKaNNlgoG2Wt95kQF7AsWy5EHBcuUJyAF/90HNA8bFhh9jvfXh1b35N9n6S8
2IkN26ROfazabcX/JRljxm4jgfKDzrwt/np3mEkrD9fesYiQtwgJfGyjjpZgEo49
ecZwREahe0omA8cg89NMuHY40RN6PNc7tIjQg9exAgMBAAGjXTBbMA8GA1UdEwEB
/wQFMAMBAQAwDgYDVR0PAQH/BAQDAgbAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAZBgNVHREEEjAQgQ50aWhzQGhvdXNlLmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEABsCTzwM+HjvDQXCfPucSqcqvdxfJsUZNMRN9RZFka8GuMpBbxhIGdTLo
w8SOKRIIqzRdznCAKf4SPZ4y5nMyOQkHLGKIRcjMnZfnJkxjyj86eUxIBAVQP7lK
RcZkj+UdRE2eakED11jRoyFEAaXbYvqa/ZwCImOLIKSh2DW2hflvpX0sdfIX89KO
QVc9Ve9vAQanJtHjjs2xbn86V1J2Ffc4bcsMrk7dofrmoYwJVrNA4wzbrWDKHfjW
2NX2V2JBK8xnEDSTywtTuVf7oEZGGKY+1yMrgsqS22aC7sOUtUwqO/Gd0UsJiaMv
LhjJg2S3a2LFQk129WJrM1CM5XOCvw==
-----END CERTIFICATE-----
EOF
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=test2, C=US
        Validity
            Not Before: Dec 15 19:56:58 2015 GMT
            Not After : Dec 14 19:56:58 2016 GMT
        Subject: CN=test2, C=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b1:9a:8f:d8:79:41:f0:8b:26:ab:f8:3c:b3:a0:
                    af:e6:a9:31:1c:de:78:5a:18:08:d4:31:9d:9f:4a:
                    6e:53:9c:4c:e2:cf:13:09:13:71:12:62:37:b4:08:
                    88:33:ab:09:55:35:25:85:e0:eb:84:4a:8a:24:60:
                    66:9c:17:df:d1:f9:e2:67:e7:c1:6b:9f:33:83:82:
                    56:ac:98:33:0b:c5:42:bc:91:61:85:4e:42:25:4a:
                    92:fb:d9:cb:55:6d:94:7d:6b:12:46:18:24:d1:0e:
                    eb:42:17:31:4c:cd:a7:6c:9c:35:c4:32:6a:06:00:
                    f2:c2:48:aa:d0:f0:31:5d:53:29:97:49:4b:73:a4:
                    a6:8d:36:58:28:1b:65:ad:f7:99:10:17:b0:2c:5b:
                    2e:44:1c:17:2e:50:9c:80:17:ff:74:1c:d0:3c:6c:
                    58:61:f6:3b:df:5e:1d:5b:df:93:7d:9f:a4:bc:d8:
                    89:0d:db:a4:4e:7d:ac:da:6d:c5:ff:25:19:63:c6:
                    6e:23:81:f2:83:ce:bc:2d:fe:7a:77:98:49:2b:0f:
                    d7:de:b1:88:90:b7:08:09:7c:6c:a3:8e:96:60:12:
                    8e:3d:79:c6:70:44:46:a1:7b:4a:26:03:c7:20:f3:
                    d3:4c:b8:76:38:d1:13:7a:3c:d7:3b:b4:88:d0:83:
                    d7:b1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Extended Key Usage:
                E-mail Protection, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                email:[hidden email]
    Signature Algorithm: sha256WithRSAEncryption
         06:c0:93:cf:03:3e:1e:3b:c3:41:70:9f:3e:e7:12:a9:ca:af:
         77:17:c9:b1:46:4d:31:13:7d:45:91:64:6b:c1:ae:32:90:5b:
         c6:12:06:75:32:e8:c3:c4:8e:29:12:08:ab:34:5d:ce:70:80:
         29:fe:12:3d:9e:32:e6:73:32:39:09:07:2c:62:88:45:c8:cc:
         9d:97:e7:26:4c:63:ca:3f:3a:79:4c:48:04:05:50:3f:b9:4a:
         45:c6:64:8f:e5:1d:44:4d:9e:6a:41:03:d7:58:d1:a3:21:44:
         01:a5:db:62:fa:9a:fd:9c:02:22:63:8b:20:a4:a1:d8:35:b6:
         85:f9:6f:a5:7d:2c:75:f2:17:f3:d2:8e:41:57:3d:55:ef:6f:
         01:06:a7:26:d1:e3:8e:cd:b1:6e:7f:3a:57:52:76:15:f7:38:
         6d:cb:0c:ae:4e:dd:a1:fa:e6:a1:8c:09:56:b3:40:e3:0c:db:
         ad:60:ca:1d:f8:d6:d8:d5:f6:57:62:41:2b:cc:67:10:34:93:
         cb:0b:53:b9:57:fb:a0:46:46:18:a6:3e:d7:23:2b:82:ca:92:
         db:66:82:ee:c3:94:b5:4c:2a:3b:f1:9d:d1:4b:09:89:a3:2f:
         2e:18:c9:83:64:b7:6b:62:c5:42:4d:76:f5:62:6b:33:50:8c:
         e5:73:82:bf


--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Blumenthal, Uri - 0553 - MITLL
On 12/15/15, 15:34 , "openssl-dev on behalf of Viktor Dukhovni"
<[hidden email] on behalf of [hidden email]>
wrote:

>On Tue, Dec 15, 2015 at 08:04:45PM +0000, Blumenthal, Uri - 0553 - MITLL
>wrote:
>> It appears that openssl verify refuses to deal with self-signed
>> certificates?
>
>You mean the command-line utility?

Yes.

>>$ openssl verify -verbose -purpose sslclient -purpose smimesign test2.pem
>>
>> test2.pem: CN = test2, C = US
>>
>> error 20 at 0 depth lookup:unable to get local issuer certificate
>
>No CAfile, no trust.
>
>And your particular certificate has:
>
>            X509v3 Basic Constraints: critical
>                CA:FALSE
>
>which does prevent it from verifying itself.  The "CA:FALSE"
>constraint is only really useful in certificates issued from a
>different key.  No security benefit in setin it in self-signed
>certificates.
I see. So what you’re saying is if I want self-signed certs to be
verifiable that way - they must not have that “non-CA” constraint. Makes
sense.

If I want to “partially” verify a certificate via the command-line utility
- e.g. when I don’t have the issuing certificate at hand, is there a way
to tell openssl tool to go just as far as it can *without* climbing up the
cert chain? I understand and agree that it significantly reduces the value
of the verification - but in some [of my use] cases it is sufficient. If
it is not supported now - would it be possible to add such capability as
an option?

Thanks!

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni

> On Dec 15, 2015, at 4:21 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
>> And your particular certificate has:
>>
>>           X509v3 Basic Constraints: critical
>>               CA:FALSE
>>
>> which does prevent it from verifying itself.  The "CA:FALSE"
>> constraint is only really useful in certificates issued from a
>> different key.  No security benefit in setin it in self-signed
>> certificates.
>
> I see. So what you’re saying is if I want self-signed certs to be
> verifiable that way - they must not have that “non-CA” constraint. Makes
> sense.

Yes, that's what I'm saying.

> If I want to “partially” verify a certificate via the command-line utility
> - e.g. when I don’t have the issuing certificate at hand, is there a way
> to tell openssl tool to go just as far as it can *without* climbing up the
> cert chain? I understand and agree that it significantly reduces the value
> of the verification - but in some [of my use] cases it is sufficient. If
> it is not supported now - would it be possible to add such capability as
> an option?

What does "partially verify mean?  Without the issuer's public key, you
can't check the signature, so all you can do is *parse* the certificate,
but you can't *verify* it.  The "x509" utility parses certificates, what
do you want to do that goes beyond parsing, but stops short of checking
the issuer signature?

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Nounou Dadoun
I have actually asked a variant on this question in the path, I would rephrase it as I have a certificate chain which doesn't go all the way back to a self-signed cert.  But I "trust" the highest certificate in the chain that I have; is there a way of telling openssl that once it hits this "trusted" certificate, it can stop and return the result.  As I recall, the answer was no .. N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


This email, including any files attached hereto (the “email”), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide.



-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Viktor Dukhovni
Sent: Tuesday, December 15, 2015 1:36 PM
To: [hidden email]
Subject: Re: [openssl-dev] Cannot verify self-signed certificates?


> On Dec 15, 2015, at 4:21 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
>> And your particular certificate has:
>>
>>           X509v3 Basic Constraints: critical
>>               CA:FALSE
>>
>> which does prevent it from verifying itself.  The "CA:FALSE"
>> constraint is only really useful in certificates issued from a
>> different key.  No security benefit in setin it in self-signed
>> certificates.
>
> I see. So what you’re saying is if I want self-signed certs to be
> verifiable that way - they must not have that “non-CA” constraint.
> Makes sense.

Yes, that's what I'm saying.

> If I want to “partially” verify a certificate via the command-line
> utility
> - e.g. when I don’t have the issuing certificate at hand, is there a
> way to tell openssl tool to go just as far as it can *without*
> climbing up the cert chain? I understand and agree that it
> significantly reduces the value of the verification - but in some [of
> my use] cases it is sufficient. If it is not supported now - would it
> be possible to add such capability as an option?

What does "partially verify mean?  Without the issuer's public key, you can't check the signature, so all you can do is *parse* the certificate, but you can't *verify* it.  The "x509" utility parses certificates, what do you want to do that goes beyond parsing, but stops short of checking the issuer signature?

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni

> On Dec 15, 2015, at 5:00 PM, Nounou Dadoun <[hidden email]> wrote:
>
> I have actually asked a variant on this question in the path, I would rephrase it as I have a certificate chain which doesn't go all the way back to a self-signed cert.  But I "trust" the highest certificate in the chain that I have; is there a way of telling openssl that once it hits this "trusted" certificate, it can stop and return the result.  As I recall, the answer was no .. N

With OpenSSL 1.0.2 or greater you can use trust-anchors that are not
self-signed.

API:
        X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_PARTIAL_CHAIN);

CLI:
        openssl verify -partial_chain ...

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Viktor Dukhovni
>>If I want to “partially” verify a certificate via the command-line

>>utility
>> - e.g. when I don’t have the issuing certificate at hand, is there a way
>> to tell openssl tool to go just as far as it can *without* climbing up
>>the
>> cert chain? I understand and agree that it significantly reduces the
>>value
>> of the verification - but in some [of my use] cases it is sufficient. If
>> it is not supported now - would it be possible to add such capability as
>> an option?
>
>What does "partially verify mean?  Without the issuer's public key, you
>can't check the signature, so all you can do is *parse* the certificate,
>but you can't *verify* it.
Yes, you’re 100% correct.

By “partially verify” I mean “check for (in)consistencies”, malformed
attributes, extensions disagreeing with “-purpose”, etc.

Also, I may not have *all* of the chain available - in which case I’d like
this command-line tool to stop at the last *available* certificate of the
verification chain, telling me whether the check was OK or not *within the
available chain*.


>The "x509" utility parses certificates, what do you want to do that goes
>beyond parsing, but stops short of checking
>the issuer signature?

As I said above - match of the extensions to “-purpose”, for one thing…
“x509” just parses. But I guess you’re correct - if I don’t have the chain
to verify signatures, eyeballing the extensions printed with “-text
-noout" would in the end give the same result. Having a tool doing it for
me would be more convenient, but I see your point.

Also, in your next email you mention “openssl verify -partial_chain”.
Alas, I don’t see this option:

$ openssl version
OpenSSL 1.0.2e 3 Dec 2015
$ openssl verify --help
usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose]
[-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2
...
recognized usages:
        sslclient SSL client
        sslserver SSL server
        nssslserver Netscape SSL server
        smimesign S/MIME signing
        smimeencrypt S/MIME encryption
        crlsign   CRL signing
        any       Any Purpose
        ocsphelper OCSP helper
        timestampsign Time Stamp signing
$ man verify

NAME
       verify - Utility to verify certificates.


SYNOPSIS
       openssl verify [-CApath directory] [-CAfile file] [-purpose
purpose] [-policy arg]
       [-ignore_critical] [-attime timestamp] [-check_ss_sig] [-crlfile
file] [-crl_download]
       [-crl_check] [-crl_check_all] [-policy_check] [-explicit_policy]
[-inhibit_any] [-inhibit_map]
       [-x509_strict] [-extended_crl] [-use_deltas] [-policy_print]
[-no_alt_chains] [-untrusted
       file] [-help] [-issuer_checks] [-trusted file] [-verbose] [-]
[certificates]


DESCRIPTION
       The verify command verifies certificate chains.




Thanks!

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni

> On Dec 15, 2015, at 5:30 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> Also, in your next email you mention “openssl verify -partial_chain”.
> Alas, I don’t see this option:
>
> $ openssl version
> OpenSSL 1.0.2e 3 Dec 2015
> $ openssl verify --help
> usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose]
> [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2
> ...
> recognized usages:
> sslclient SSL client
> sslserver SSL server
> nssslserver Netscape SSL server
> smimesign S/MIME signing
> smimeencrypt S/MIME encryption
> crlsign   CRL signing
> any       Any Purpose
> ocsphelper OCSP helper
> timestampsign Time Stamp signing

That's fine, but have you tried it?

> $ man verify
>
> NAME
>       verify - Utility to verify certificates.
>
>
> SYNOPSIS
>       openssl verify [-CApath directory] [-CAfile file] [-purpose purpose] [-policy arg]
>       [-ignore_critical] [-attime timestamp] [-check_ss_sig] [-crlfile file] [-crl_download]
>       [-crl_check] [-crl_check_all] [-policy_check] [-explicit_policy] [-inhibit_any] [-inhibit_map]
>       [-x509_strict] [-extended_crl] [-use_deltas] [-policy_print] [-no_alt_chains] [-untrusted
>       file] [-help] [-issuer_checks] [-trusted file] [-verbose] [-] [certificates]

That's fine, but have you tried it?  The option is documented in
1.1.0, and not 1.0.2, and yet it is available in both.

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Blumenthal, Uri - 0553 - MITLL
On 12/15/15, 17:51 , "openssl-dev on behalf of Viktor Dukhovni"
<[hidden email] on behalf of [hidden email]>
wrote:

>>On Dec 15, 2015, at 5:30 PM, Blumenthal, Uri - 0553 - MITLL
>><[hidden email]> wrote:
>>
>>$ openssl verify --help
>> usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose
>>purpose]
>> [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1
>>cert2
>> ...
>
>That's fine, but have you tried it?  The option is documented in
>1.1.0, and not 1.0.2, and yet it is available in both.
Yeah… And it does not complain… Unfortunately, right now most of my cert
chains are of length 1, so I can’t give it a good try. :-(
And without a decent description of what it is supposed to do, I’m a bit
lost...

$ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -partial_chain
-purpose sslclient RabbitMQ_Dev.pem
RabbitMQ_Dev.pem: OK
$ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -purpose
sslclient RabbitMQ_Dev.pem
RabbitMQ_Dev.pem: OK
$

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni
On Tue, Dec 15, 2015 at 10:56:59PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -partial_chain
> -purpose sslclient RabbitMQ_Dev.pem
> RabbitMQ_Dev.pem: OK

Well if that CAfile yields a path to a root CA, the "-partial_chain"
option makes no difference.

> $ openssl verify -verbose -CAfile ~/Certs/RabbitMQ_CA.pem -purpose
> sslclient RabbitMQ_Dev.pem
> RabbitMQ_Dev.pem: OK

If it is OK without "-partial_chain", then your root CA is in there.

    $ OpenSSL_1_0_2/bin/openssl verify -CAfile issuer.pem leaf.pem
    leaf.pem: O = example.com, CN = clica Signing Cert
    error 2 at 1 depth lookup:unable to get issuer certificate

    $ OpenSSL_1_0_2/bin/openssl verify -partial_chain -CAfile issuer.pem leaf.pem
    leaf.pem: OK

    $ OpenSSL_1_0_2/bin/openssl verify -CAfile root.pem -untrusted chain.pem leaf.pem
    leaf.pem: OK

The entire chain: leaf, issuer, root is in chain.pem.
Just the root CA: is in root.pem
Just the issuer CA: is in issuer.pem
The leaf CA: is the first certificate in leaf.pem (this can just be chain.pem)

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni
In reply to this post by Blumenthal, Uri - 0553 - MITLL

> On Dec 15, 2015, at 5:56 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> And without a decent description of what it is supposed to do, I’m a bit
> lost...

The "-partial_chain" option is (partially :-) documented at:

   https://www.openssl.org/docs/manmaster/apps/verify.html

   -partial_chain
    Allow partial certificate chain if at least one certificate is in trusted store.

Note, that you typically also need to use the "-untrusted" option to provide
the rest of the chain, since only the first certificate is read from the file
containing the target certificate (perhaps a misfeature, the rest should likely
automatically be added as "untrusted").

As a final note, with "-partial_chain" any certificate always verifies against
itself regardless of purpose or basic constraints.  Thus, for example:

   $ openssl verify -partial_chain -purpose crlsign foo.pem foo.pem

will always succeed, provided foo.pem contains a certificate that does not
fail to parse.

I'm not quite sure why the purpose is ignored, it might be more useful
if the purpose were still checked (after any explicit auxiliary trust
settings via "BEGIN TRUSTED CERTIFICATE").  For example, with the certificate
below in CAfile checking itself, one might expect "-purpose sslclient" to succeed,
and "-purpose smimesign" to fail, or at perhaps "-purpose sslserver" to succeed
and "smimesign" to fail.  It is not obvious whether the extended key usage should
be used at all, or used only in the absence of explicit trust settings, ...
or whether the current behaviour is correct (all in the context of -partial_chain).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Issuer CA
        Validity
            Not Before: Dec 13 23:23:52 2015 GMT
            Not After : Apr 15 23:23:52 3015 GMT
        Subject: CN = example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:66:49:95:f4:7b:de:35:e7:b4:de:48:b2:58:e9:
                    e8:a0:7a:de:bb:db:86:3b:3d:06:f4:81:a1:94:6c:
                    83:da:9f:56:cf:f4:d9:38:9b:85:5d:2f:36:4b:15:
                    85:b0:c7:34:fc:fa:26:30:26:96:4f:f5:a4:30:8b:
                    3f:c8:79:bd:b8
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                5B:20:CA:41:7D:90:88:C7:A4:C0:17:CB:6C:0C:1C:73:9B:B0:7D:8A
            X509v3 Authority Key Identifier:
                keyid:7A:B7:5A:3C:D2:95:CA:5D:F7:C5:15:09:16:E1:8F:F5:CC:37:6A:15

            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:example.com
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:1f:21:c9:03:2a:5c:8a:93:87:2d:3f:4a:ef:32:1a:
         95:74:dd:95:6d:43:bd:93:c3:69:94:4c:72:d6:90:28:58:02:
         21:00:c8:b3:29:0d:7a:f3:7e:57:1a:84:d7:04:db:ad:33:9d:
         29:87:d4:18:52:dc:59:36:f2:12:94:70:63:91:11:81
Trusted Uses:
  TLS Web Client Authentication
Rejected Uses:
  E-mail Protection
-----BEGIN TRUSTED CERTIFICATE-----
MIIBlDCCATugAwIBAgIBAjAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlJc3N1ZXIg
Q0EwIBcNMTUxMjEzMjMyMzUyWhgPMzAxNTA0MTUyMzIzNTJaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZkmV9HveNee0
3kiyWOnooHreu9uGOz0G9IGhlGyD2p9Wz/TZOJuFXS82SxWFsMc0/PomMCaWT/Wk
MIs/yHm9uKN6MHgwHQYDVR0OBBYEFFsgykF9kIjHpMAXy2wMHHObsH2KMB8GA1Ud
IwQYMBaAFHq3WjzSlcpd98UVCRbhj/XMN2oVMAkGA1UdEwQCMAAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwID
RwAwRAIfIckDKlyKk4ctP0rvMhqVdN2VbUO9k8NplExy1pAoWAIhAMizKQ16835X
GoTXBNutM50ph9QYUtxZNvISlHBjkRGBMBgwCgYIKwYBBQUHAwKgCgYIKwYBBQUH
AwQ=
-----END TRUSTED CERTIFICATE-----

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Cannot verify self-signed certificates?

Viktor Dukhovni
On Wed, Dec 16, 2015 at 06:56:59PM -0500, Viktor Dukhovni wrote:

> As a final note, with "-partial_chain" any certificate always verifies against
> itself regardless of purpose or basic constraints.  Thus, for example:
>
>    $ openssl verify -partial_chain -purpose crlsign foo.pem foo.pem
>
> will always succeed, provided foo.pem contains a certificate that does not
> fail to parse.
>
> I'm not quite sure why the purpose is ignored, it might be more useful
> if the purpose were still checked (after any explicit auxiliary trust
> settings via "BEGIN TRUSTED CERTIFICATE").

It is easy to restore checking the purpose, it seems likely that
suppression of that check was an oversight.  However, I think that
if the leaf certificate is actually trusted and has auxiliary trust
settings, those probably should kick in, so the patch below is
likely not quite the whole story.

diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 3acb374..864283e 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -617,8 +617,8 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
         purpose = ctx->param->purpose;
     }
 
-    /* Check all untrusted certificates */
-    for (i = 0; i < ctx->last_untrusted; i++) {
+    /* Check all untrusted certificates, and always the leaf cert */
+    for (i = 0; i == 0 || i < ctx->last_untrusted; i++) {
         int ret;
         x = sk_X509_value(ctx->chain, i);
         if (!(ctx->param->flags & X509_V_FLAG_IGNORE_CRITICAL)

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev