Hi,
I've just installed openssl version 1.1.0-pre2-dev in my home directory
on a Fedora box in order to see the new alt chain building in operation.
I'm testing this in a lab environment by initially generating a straight
hierarchy of root CA, policy CA, issuing CA and end-entity (a web
server) all with a really original naming convention as follows:
Gareth Williams Root CA
Gareth Williams Policy CA
Gareth Williams Issuing CA
office.garethwilliams.me.uk (test webserver)
I've concatenated the policy CA and issuing CA certificate into a single
file, and running:
openssl verify -trusted Gareth_Williams_Root_CA.crt -untrusted
chain.crt office.garethwilliams.me.uk
works.
I now try to cross-certify by adding another Root CA (Example Root CA)
and use that to sign the original Gareth Williams Policy CA certificate
signing request, then add this new certificate to the chain.crt file:
Gareth Williams Root CA Example Root CA
| |
Gareth Williams Policy CA Gareth Williams Policy CA
| |
+----------------+------------------+
|
Gareth Williams Issuing CA
|
office.garethwilliams.me.uk
When I run the openssl verify command above again, I get different
results depending on the order of the (now) two Gareth Williams Policy
CA certificates in the chain file:
With -trusted Gareth_Williams_Root_CA and a chain.crt as follows (from
openssl x509 -noout -subject -subject_hash -issuer -issuer_hash),
openssl successfully verifies.
subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA
ec2241cd
issuer= /C=GB/O=Example/CN=Example Root CA
83507648
subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA
ec2241cd
issuer= /C=GB/O=Gareth Williams/CN=Gareth Williams Root CA
fb71fe2c
subject= /C=GB/O=Gareth Williams/CN=Gareth Williams Issuing CA
d4f031ac
issuer= /C=GB/O=Gareth Williams/CN=Gareth Williams Policy CA
ec2241cd
However, if I swap the order of the two Gareth Williams Policy CA
certificate OR change -trusted to Example_Root_CA.crt then openssl
verify fails.
It seems as if order matters in the collection of certificates passed
using the -untrusted option. I was under the impression that the whole
idea of this alternative chain building algorithm was that it would just
figure it out itself.
I've confirmed the chain works fine by configuring apache with the
end-entity certificate/key and the chain certificate file at which point
Firefox happily chains up to either root certificate (I
installed/uninstalled each root in turn). It seems that only openssl
verify complains. I believe this is identical to the issue reported and
resolved in bug:
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3621
but doesn't seem to be working for me.
So the million dollar question is: What's happening? Is it A) There's
a regression here? B) I'm a biff?
I'd go for B) myself. If you do agree with me (option B) then could
someone please explain what's happening and/or what should be happening.
Thanks in advance,
Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4175 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151231/08e735da/attachment-0001.bin>
