[openssl-dev] Cannot verify self-signed certificates?

[Viktor Dukhovni]

> On Dec 15, 2015, at 5:56 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> 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.