Problems with cross-signed certificates and Authority Key Info

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with cross-signed certificates and Authority Key Info

Hubert Kario
I have 4 key pairs:
 * CA1
 * CA2
 * subCA
 * server

the CA1 and CA2 are self signed root CAs

subCA has two certificates, one signed by CA1 and one signed by CA2

server has a certificate signed by subCA (server.pem file)
and also has Authority Key Identifier with DirName that points to CA1
(server2.pem file).

The problem happens when I try to verify the server certificate
using chain that links up to CA1 and one that links to CA2.

That is:
$ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server2.pem
server2.pem: OK

$ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server2.pem
server2.pem: CN = localhost
error 20 at 0 depth lookup:unable to get local issuer certificate

While
$ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server.pem
server.pem: OK
$ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server.pem
server.pem: OK

As far as I know, the Authority Key IDs are supposed just to aid
path resolution, not completely guide it. Is that not correct?

Also, I think that the DirName should point to
/O=Example intermediate CA, not to /CN=CA1 when the ceritifcate
is signed with
authorityKeyIdentifier=keyid:always,issuer:always
extension, doesn't it?


The difference between the server certificates is:

$ diff -u <(openssl x509 -in server.pem -noout -text) <(openssl x509 -in server2.pem -noout -text)
--- /dev/fd/63  2014-07-24 13:36:52.286372737 +0200
+++ /dev/fd/62  2014-07-24 13:36:52.286372737 +0200
@@ -1,12 +1,12 @@
 Certificate:
     Data:
         Version: 3 (0x2)
-        Serial Number: 1 (0x1)
+        Serial Number: 2 (0x2)
     Signature Algorithm: sha256WithRSAEncryption
         Issuer: O=Example intermediate CA
         Validity
-            Not Before: Jul 24 11:03:52 2014 GMT
-            Not After : Jul 24 11:03:52 2015 GMT
+            Not Before: Jul 24 11:03:53 2014 GMT
+            Not After : Jul 24 11:03:53 2015 GMT
         Subject: CN=localhost
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
@@ -38,19 +38,24 @@
                 TLS Web Server Authentication
             X509v3 Subject Key Identifier:
                 02:39:CD:9F:37:E2:3B:81:5F:73:F9:71:A4:BD:C9:3B:67:94:2D:8A
+            X509v3 Authority Key Identifier:
+                keyid:F3:7C:85:7F:05:DF:12:C2:21:8C:4C:58:FD:A4:33:93:E2:32:D6:54
+                DirName:/CN=CA1
+                serial:02
+
     Signature Algorithm: sha256WithRSAEncryption
-         25:a3:4f:12:fc:f0:f9:af:f0:2c:2c:31:7e:c2:0e:a9:9a:14:
-         6b:3e:67:ef:ae:b3:6d:b1:0f:67:b6:ed:49:d1:71:df:cc:fc:
-         19:7f:c3:9d:52:98:59:c5:62:65:6e:37:b8:17:cf:9c:d5:fd:
-         59:f3:8c:b1:47:d0:9a:1e:9c:31:18:79:b4:57:1f:24:8f:63:
-         1d:7f:2e:6f:06:c7:f8:d8:25:c2:6b:54:3a:2f:f8:43:49:ec:
-         32:a9:19:26:1c:37:54:7f:bd:36:3c:f5:ee:d2:bd:25:38:01:
-         db:25:22:c5:7f:a8:f1:6e:9f:44:78:8c:15:2c:03:91:3c:cb:
-         4d:c5:5d:5b:93:44:f4:91:90:c7:28:29:e6:87:2c:f6:b7:a0:
-         0c:8c:f6:fd:73:a9:ea:cf:35:be:56:db:3c:1b:25:36:30:1f:
-         f1:14:34:4b:b5:17:a3:ee:da:be:9c:38:17:62:d1:72:72:d2:
-         9d:fd:34:90:47:d4:4b:d8:19:95:f5:0c:cf:af:bc:2c:0c:83:
-         ae:68:1c:d8:e9:77:21:e6:43:bb:db:9f:0e:e5:dd:d9:a9:40:
-         83:f0:b3:72:9e:b2:33:e9:fb:bc:f1:fb:74:26:7f:96:26:c6:
-         b0:48:da:f4:61:c4:b4:68:28:1e:73:43:39:5c:b0:1f:5a:0d:
-         1d:f9:35:13
+         8f:78:c3:0e:f4:bb:3a:fb:f2:b1:65:2c:9c:55:94:25:33:8d:
+         57:4a:e1:10:ea:9a:44:e0:d3:ff:48:9d:d6:4b:c6:fc:04:2a:
+         4f:a3:b5:99:24:b2:78:29:ad:63:0a:00:03:6a:57:24:52:86:
+         bc:a3:45:01:87:6a:d6:59:8d:e8:ac:43:f9:fa:c8:dc:15:a2:
+         0c:f0:b9:cf:50:f9:9f:c7:60:0e:29:0e:80:b2:e7:9e:ab:18:
+         7f:ae:a3:7f:90:34:b3:68:43:23:27:0d:e6:a0:22:7c:17:c5:
+         ee:67:f1:8a:5c:27:51:10:e9:94:28:b1:95:9f:98:58:11:4d:
+         eb:05:a8:a1:51:cb:48:36:59:68:32:57:65:76:1b:ee:d1:45:
+         b6:c5:2d:ec:71:84:23:f1:88:51:3a:ff:a3:54:ed:3d:a0:97:
+         25:b4:fe:a7:7e:a3:2f:b4:3c:c1:2f:33:b5:13:87:09:12:34:
+         5c:05:e8:77:68:8d:ec:d9:29:aa:10:c7:20:4a:f2:80:9d:9f:
+         49:b5:39:cb:06:e4:69:8d:68:ea:f9:2d:f6:d0:4a:55:1c:12:
+         6b:d7:10:6b:b6:c2:64:18:11:ff:05:22:4f:d8:37:cf:8e:d0:
+         cd:5a:fc:cb:93:ee:99:23:ff:db:f1:88:2d:58:2f:51:02:af:
+         f4:82:6f:87
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

ca1.pem (5K) Download Attachment
ca2.pem (5K) Download Attachment
server.pem (5K) Download Attachment
server2.pem (5K) Download Attachment
subca-ca1.pem (5K) Download Attachment
subca-ca2.pem (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with cross-signed certificates and Authority Key Info

Dr. Stephen Henson
On Thu, Jul 24, 2014, Hubert Kario wrote:

> I have 4 key pairs:
>  * CA1
>  * CA2
>  * subCA
>  * server
>
> the CA1 and CA2 are self signed root CAs
>
> subCA has two certificates, one signed by CA1 and one signed by CA2
>
> server has a certificate signed by subCA (server.pem file)
> and also has Authority Key Identifier with DirName that points to CA1
> (server2.pem file).
>
> The problem happens when I try to verify the server certificate
> using chain that links up to CA1 and one that links to CA2.
>
> That is:
> $ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server2.pem
> server2.pem: OK
>
> $ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server2.pem
> server2.pem: CN = localhost
> error 20 at 0 depth lookup:unable to get local issuer certificate
>
> While
> $ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server.pem
> server.pem: OK
> $ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server.pem
> server.pem: OK
>
> As far as I know, the Authority Key IDs are supposed just to aid
> path resolution, not completely guide it. Is that not correct?
>

Yes that's a known limitation with the current AKID handling. If you omit the
issuer and serial number part of AKID there should be no problems.


> Also, I think that the DirName should point to
> /O=Example intermediate CA, not to /CN=CA1 when the ceritifcate
> is signed with
> authorityKeyIdentifier=keyid:always,issuer:always
> extension, doesn't it?
>

I think that's covered by this:

https://www.openssl.org/support/faq.html#USER15

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Problems with cross-signed certificates and Authority Key Info

Hubert Kario
----- Original Message -----

> From: "Dr. Stephen Henson" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, 24 July, 2014 2:58:00 PM
> Subject: Re: Problems with cross-signed certificates and Authority Key Info
>
> On Thu, Jul 24, 2014, Hubert Kario wrote:
>
> > I have 4 key pairs:
> >  * CA1
> >  * CA2
> >  * subCA
> >  * server
> >
> > the CA1 and CA2 are self signed root CAs
> >
> > subCA has two certificates, one signed by CA1 and one signed by CA2
> >
> > server has a certificate signed by subCA (server.pem file)
> > and also has Authority Key Identifier with DirName that points to CA1
> > (server2.pem file).
> >
> > The problem happens when I try to verify the server certificate
> > using chain that links up to CA1 and one that links to CA2.
> >
> > That is:
> > $ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server2.pem
> > server2.pem: OK
> >
> > $ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server2.pem
> > server2.pem: CN = localhost
> > error 20 at 0 depth lookup:unable to get local issuer certificate
> >
> > While
> > $ openssl verify -CAfile ca2.pem -untrusted subca-ca2.pem server.pem
> > server.pem: OK
> > $ openssl verify -CAfile ca1.pem -untrusted subca-ca1.pem server.pem
> > server.pem: OK
> >
> > As far as I know, the Authority Key IDs are supposed just to aid
> > path resolution, not completely guide it. Is that not correct?
> >
>
> Yes that's a known limitation with the current AKID handling. If you omit the
> issuer and serial number part of AKID there should be no problems.

Is there an rt ticket that tracks it?
 

> > Also, I think that the DirName should point to
> > /O=Example intermediate CA, not to /CN=CA1 when the ceritifcate
> > is signed with
> > authorityKeyIdentifier=keyid:always,issuer:always
> > extension, doesn't it?
> >
>
> I think that's covered by this:
>
> https://www.openssl.org/support/faq.html#USER15

yes, that's exactly it. Thank you.


--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]