@David von Oheimb I will update to a new version and try again.
Good. Ideally try also a current 3.0.0 alpha release because
there have been some changes to cert chain building and
verification recently.
Understood, but my point was on a different aspect:To append cert is to make sure new cert and old cert both exist in trust store, thus when server switches cert, it can be trusted by client.
The chain building will take the first matching cert, so if you want to prefer the new cert, it must be in the list *before* the old one -
in other words, prepend the new cert to the list rather than appending to it.
@Jochen actually, the certs have different SN, which indeed is not consistent with the man doc
Different certs with the same issuer indeed must have
different SNs (except in the special case I mention below).
See also RFC 5280 section 4.1.2.2 https://tools.ietf.org/html/rfc5280#section-4.1.2.2:
It MUST be unique for each certificate issued by a given CA
(i.e., the issuer name and serial number identify a unique certificate).
Yet there is a different inconsistency in what you write:
You refer to them as CA certs, but they are not: they do no have a basicConstraints field with the cA bit set.The thing that confuses me is that CURL (compiled with gnutls) and Golang works.
below is my ca.crt file, I am not sure where it went wrong, maybe just my wrong behavior?
And as far as I understand your scenario, they are not used to issue other certs but by some (TLS) server,
so they really are end-entity (EE) certs, not CA certs, and it looks like this is correct in your application scenario.
Directly trusted self-issued EE certs (which may be self-signed or not) are a special situation.
This has been clarified in RFC 6818 (which updates RFC 5280) https://tools.ietf.org/html/rfc6818#section-2:
| Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note | that use of self-issued certificates and self-signed certificates | issued by entities other than CAs are outside the scope of this | specification. Thus, for example, a web server or client might | generate a self-signed certificate to identify itself. These | certificates and how a relying party uses them to authenticate | asserted identities are both outside the scope of RFC 5280.So the path building and verification, as well as other checks defined RFC 5280, does not apply to them at all!
They are essentially just a convenient container for a public key, where it is optional to check expiration etc.
Unfortunately, when using such certs for TLS connections etc.,
still verification is done on them, which may fail.
After renaming your ca.crt file to ee.crt for clarity and
extracting the first cert in ee1.crt and the second one in
ee2.crt,
when verifying these directly trusted certs one gets the problem
you reported:
openssl verify -x509_strict -trusted ee.crt ee1.crt
ee1.crt: OK
openssl verify -x509_strict -trusted ee.crt ee2.crt
C = US, ST = CA, L = Palo Alto, O = VMware, CN =
nsxmanager.pks.vmware.local
error 18 at 0 depth lookup: self signed certificate
error ee2.crt: verification failed
So as I wrote before, unfortunately the path building picks up
the first matching cert from ee.crt,
which is the one in ee1.crt (i.e., your old one), and does not try
the second one (i.e., your new one).
This happens also with the latest OpenSSL pre-3.0.0 master.
A solution is to add both the subjectKeyIdentifier and
authorityKeyIdentifier extensions to your certs,
for instance like this:
echo >ee.cnf "
prompt = no
distinguished_name = my_server
x509_extensions = my_exts
[my_server]
commonName = test
[my_exts]
basicConstraints = CA:false
subjectKeyIdentifier=hash
authorityKeyIdentifier = keyid"
openssl req -config ee.cnf -new -x509 -out ee1.crt -nodes -keyout
ee1.pem
openssl req -config ee.cnf -new -x509 -out ee2.crt -nodes -keyout
ee2.pem
cat ee1.crt ee2.crt >ee.crt
The subjectKeyIdentifier and authorityKeyIdentifier extensions
are generally recommend
(and actually required to add for certs that are RFC 5280
compliant)
because they help for correct chain building, and indeed also in
this case they do:
openssl verify -x509_strict -trusted ee.crt ee1.crt
ee1.crt: OK
openssl verify -x509_strict -trusted ee.crt ee2.crt
ee2.crt: OK
Regards,
David
