Installing a certificate chain

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

Installing a certificate chain

Brian Candler
I'm trying to get a client to verify a server certificate signed by a sub-CA
when the client has only the root CA certificate.

I'm using TinyCA (GUI wrapper around OpenSSL) as the CA. Here's what I've
done:

1. Created a root CA (CN=root.ca.linnet.org)
2. Created a sub CA under this (CN=sub.ca.linnet.org)
3. Created a CSR and signed it by the sub CA
4. Installed the certificate in a small server

    #!/bin/sh
    cd content
    openssl s_server -cert ../server.example.com-cert.pem \
      -key ../server.example.com-key.pem \
      -CApath /etc/ssl/certs \
      -WWW

5. Installed the root CA's certificate under /etc/ssl/certs and re-ran
   c_rehash to incorporate it.

However, when the client connects, it is not presented with a full
certificate chain back to the root, but just the certificate signed by the
subCA:

    $ openssl s_client -connect localhost:4433 -CApath /etc/ssl/certs -showcerts
    ...
    ---
    Certificate chain
     0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com
       i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/emailAddress=[hidden email]
    ---

As a result, even though the client has the root certificate available
(CN=root.ca.linnet.org), it's unable to verify the certificate presented.

Somehow, I need to get the server to present a full certificate chain to the
client.

I tried appending the sub CA's own certificate (signed by the root CA) to
server.example.com-cert.pem, but that didn't make any difference. If I
swapped the two around, so that the sub CA's certificate is first, then
OpenSSL won't start:

$ ./server.sh
Using default temp DH parameters
Enter PEM pass phrase:
unable to get private key from '../server.example.com-key.pem'
86322:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509/x509_cmp.c:389:

Anyway, it's not clear to me whether the certificate generated by TinyCA is
incomplete, or whether there's some additional configuration required by the
server to get it to send the chain. I'd be very grateful if someone could
point me in the right direction.

The certificates and their decoding are attached below.

Regards,

Brian.

Here are the two certificates, which currently are appended together in
server.example.com-cert.pem, although it seems only the first one is used.

-----BEGIN CERTIFICATE-----
MIIFLDCCAxSgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMCR0Ix
DzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkxGjAYBgNVBAMTEXN1Yi5jYS5saW5uZXQub3JnMRww
GgYJKoZIhvcNAQkBFg1jYUBsaW5uZXQub3JnMB4XDTA2MDIyNzA5NTQ1OVoXDTA3
MDIyNzA5NTQ1OVowXTELMAkGA1UEBhMCR0IxDzANBgNVBAcTBkxvbmRvbjEgMB4G
A1UEChMXVGVzdCBzZXJ2ZXIgY2VydGlmaWNhdGUxGzAZBgNVBAMTEnNlcnZlci5l
eGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr3UiikWgAhQV
NFAWeXXPK+7XtbaOVKpcoL0+Ok9Cm9z+nJWJ1cpq/4zJxkRR5LFXjrRy9jqp+1Zx
aZewAmp4FsuZRhTOO47ugOKsII5Kimwekus6TK9NTScPZ8H9RyqSGekL/7COZc7a
kmmEPc0zN3CRcgPhYsD2geXtkOm/akMCAwEAAaOCAUwwggFIMAkGA1UdEwQCMAAw
EQYJYIZIAYb4QgEBBAQDAgZAMCsGCWCGSAGG+EIBDQQeFhxUaW55Q0EgR2VuZXJh
dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBS5Cjm+UPTMK/3DzRe7d9KK5Ko83zCB
tgYDVR0jBIGuMIGrgBTpiiSu+6nySxH2HwjSEw6vFlOCK6GBj6SBjDCBiTELMAkG
A1UEBhMCR0IxDzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlu
bmV0Lm9yZzEbMBkGCSqGSIb3DQEJARYMY2FAbGlubmV0Lm9nggEBMBgGA1UdEgQR
MA+BDWNhQGxpbm5ldC5vcmcwCQYDVR0RBAIwADANBgkqhkiG9w0BAQUFAAOCAgEA
H/9GBEq95+QCNJRYKmj+EJX+DjLT7r9xzZpj/uGWj5eQ6rpJzox8rcXeXWjuLa4z
Jps0h5L8EcayVM3LGo2mbYvpAqkzbH0IRX8RX5DKZS5dMwNWvjk97U1KKcTUBoU3
AwYGg4gRkYUIsx34sEyT+FTZsw+KnPJmAjgFqCgdQFncqAioLFFbEPaz/Rc8DTtv
yfWivTO4aHVS8sew0wzKcqNwQZqelMoGTrbcl3YUscPO/jVIS92X/YMwqPbUb0te
4JeUnXxGGXhyaF6dlGnZ1BfNUkPn78vHNc8pDcvjCiDN3r4UqjLs1q3TXdFya98I
apsmUcaynoyZAnn7GHIWoKkRBPVQ0CFZ5CaI5ISG0wD1t/pYq3XZm9+v1IdfAsAv
p/fw12Zo3i04aUVx9XafqJnFRm6f2n7U8QWqNtTg9nYwIzwFwQmaWUaodvCKXfRp
fEnxjCLFmoHORL/Vhr5Ym6m7Sx3bXXGcc2+G48c0EGsc7LZ8biKsBpm0B6HIhIb1
xvaz531FA21NBAH/z5kTeE1oncIRR+VdXhZ1sSirJMy0hNjqJcJH4NTHOuc0KUFe
3STpBNE7qfbGW7GskMN6ZoiqvD4UFAggs1/FGv3ZC1xFz2rO568MsBjsAvV2yd3x
y0MA0ara5qLIB+YxqYx1Wxu/jckoUpgDM2wbDJzb+iA=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIHCTCCBPGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMCR0Ix
DzANBgNVBAcTBkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEb
MBkGCSqGSIb3DQEJARYMY2FAbGlubmV0Lm9nMB4XDTA2MDIyNzA5NTIwNFoXDTE2
MDIyNTA5NTIwNFowgYkxCzAJBgNVBAYTAkdCMQ8wDQYDVQQHEwZMb25kb24xLzAt
BgNVBAoTJkNhbmRsZXIgSW5zZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRow
GAYDVQQDExFzdWIuY2EubGlubmV0Lm9yZzEcMBoGCSqGSIb3DQEJARYNY2FAbGlu
bmV0Lm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJo0SnhJcnpf
8CDjzLsO/FJYVRItFpkVK6X7icd0QgsgRVRd3svJPsspRCO4ui+WHfZWSJ2Jbq7r
K1tNAHYAoldmc3rFBZVcdz/LlaH8ZLYyC31M2psIprcSxGVRpkbvNDv3Ezgn32ci
bRAcA3lNpYv4TJt2gqkEkUpttMMXWOkliTW6gSd8BmnImGvkjgN0MrPrEUHnQ1tR
+H+RcvcaU65Vg/ZKT8nYlLhSdRWLZpDf39qfVNMWqNITY7Op7vzbWFuPDndK4dTw
O4jLZRBnYexgxM7lzWzh5ty7FiVX/crpQJsZHuiS5lAZdrpRtabjDpwBO88XjwAM
a3VFTfPWvzy4hMnA33+OXvSn+vvYEH2+GlUXbbtHrop4ak44ojaF/dL29x4t8dQG
GwdkVCT2qcHO66NETYuTqTyaIyiuqnBlIvNDZM3AQl3Z10IFkZO6J2pQAtmDC4j0
LXGSxZjdi9M3PUsafzcnKzRUFo3aGIOLa1E03ZoJaSSEFb0dbRXgKuSiOM84WW+Z
3XVIFLs9WULLKvGaGkXc9wKdb7/edFnnkEbJUKGb9IlHrQFy4t/7Vg3jDQFv9IuK
pxmvB5hR8xOhHZHbKB9DY/nWMomy18kRM1m0xykG0c8Ra8mBDFox22hs6Qj4UuS7
5ywln+pPqRsVvDI7Zy+ez2EKJWPGViWbAgMBAAGjggF4MIIBdDAdBgNVHQ4EFgQU
6Yokrvup8ksR9h8I0hMOrxZTgiswgb4GA1UdIwSBtjCBs4AUXOtxJaaMyOVNS7AK
SZMeWAGJdx6hgY+kgYwwgYkxCzAJBgNVBAYTAkdCMQ8wDQYDVQQHEwZMb25kb24x
LzAtBgNVBAoTJkNhbmRsZXIgSW5zZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRswGQYDVQQDExJyb290LmNhLmxpbm5ldC5vcmcxGzAZBgkqhkiG9w0BCQEWDGNh
QGxpbm5ldC5vZ4IJAP5hXQM6l3J+MA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4
QgEBBAQDAgEGMBcGA1UdEgQQMA6BDGNhQGxpbm5ldC5vZzArBglghkgBhvhCAQ0E
HhYcVGlueUNBIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAYBgNVHREEETAPgQ1jYUBs
aW5uZXQub3JnMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAgEAmrqO
nDrVO0ja9B7s4FXKo2nqmI68SFQdadFJYT/qa3DzQWYiARfsnOYcPEmHngEZ0epT
h4SZnY1eT0ebqjiGBqG0sdGPrLTZqV7cJfctsiHJzKplOQRLjnN6c5r8OuZ2WVH+
VTa9ofNBKdfLzEBlpeGPyM/VbClb+GCkFheB6zpFFPLvrdcA7BX1O1rZzp5yYHIZ
iXdNDcp6z+TALNyo7+63B7b+g9TL6nTjay5Tcc8mI8j4fD3N/bnjLVvl//e6TGnG
ZSUPiaP7cV8lVLuEdT6PmGjq6vPL9Pli2K8cOKUiUrkHCYAFdxfrvVD43yoCCMTf
+SVMWYePD84qC59Wcpm1t2B26XLm/NjJSx2r5nRR996BJQV6ebGYXtcWS6yb9duO
lGOOtD0jJ8KT7p0vwPekngRYL9UHGixbMg/b3nSesEiW4CQ0fduP2UUjzhuLVzTR
9jGFqAdbUa7bNzm9+Yt2zxAOMTBuJUAWR6ELccxS7EVWZi7Vl/Xxe9QdKfm2t5lb
8pwhoziu6ZtIkYVnbpp6aDgQfeY4xJouAsmmvFIYUDsvyqJfiJGHXAqSLtuOzwUj
rExZi0mNsNICbMxNuSxHrdedAsC/hiGPIZ+ZEz5MQw1uXnsVhiVUZ2TbNmLxVhD6
On4TjYNh85wVeduAX66QJqh/SBDyNH9ftDwJ7/Y=
-----END CERTIFICATE-----

They decode as follows:

$ openssl asn1parse -in a -inform pem
    0:d=0  hl=4 l=1324 cons: SEQUENCE          
    4:d=1  hl=4 l= 788 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   1 prim: INTEGER           :01
   16:d=2  hl=2 l=  13 cons: SEQUENCE          
   18:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
   29:d=3  hl=2 l=   0 prim: NULL              
   31:d=2  hl=3 l= 137 cons: SEQUENCE          
   34:d=3  hl=2 l=  11 cons: SET              
   36:d=4  hl=2 l=   9 cons: SEQUENCE          
   38:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   43:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
   47:d=3  hl=2 l=  15 cons: SET              
   49:d=4  hl=2 l=  13 cons: SEQUENCE          
   51:d=5  hl=2 l=   3 prim: OBJECT            :localityName
   56:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
   64:d=3  hl=2 l=  47 cons: SET              
   66:d=4  hl=2 l=  45 cons: SEQUENCE          
   68:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   73:d=5  hl=2 l=  38 prim: PRINTABLESTRING   :Candler Insecure Certificate Authority
  113:d=3  hl=2 l=  26 cons: SET              
  115:d=4  hl=2 l=  24 cons: SEQUENCE          
  117:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  122:d=5  hl=2 l=  17 prim: PRINTABLESTRING   :sub.ca.linnet.org
  141:d=3  hl=2 l=  28 cons: SET              
  143:d=4  hl=2 l=  26 cons: SEQUENCE          
  145:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  156:d=5  hl=2 l=  13 prim: IA5STRING         :[hidden email]
  171:d=2  hl=2 l=  30 cons: SEQUENCE          
  173:d=3  hl=2 l=  13 prim: UTCTIME           :060227095459Z
  188:d=3  hl=2 l=  13 prim: UTCTIME           :070227095459Z
  203:d=2  hl=2 l=  93 cons: SEQUENCE          
  205:d=3  hl=2 l=  11 cons: SET              
  207:d=4  hl=2 l=   9 cons: SEQUENCE          
  209:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  214:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
  218:d=3  hl=2 l=  15 cons: SET              
  220:d=4  hl=2 l=  13 cons: SEQUENCE          
  222:d=5  hl=2 l=   3 prim: OBJECT            :localityName
  227:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
  235:d=3  hl=2 l=  32 cons: SET              
  237:d=4  hl=2 l=  30 cons: SEQUENCE          
  239:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
  244:d=5  hl=2 l=  23 prim: PRINTABLESTRING   :Test server certificate
  269:d=3  hl=2 l=  27 cons: SET              
  271:d=4  hl=2 l=  25 cons: SEQUENCE          
  273:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  278:d=5  hl=2 l=  18 prim: PRINTABLESTRING   :server.example.com
  298:d=2  hl=3 l= 159 cons: SEQUENCE          
  301:d=3  hl=2 l=  13 cons: SEQUENCE          
  303:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  314:d=4  hl=2 l=   0 prim: NULL              
  316:d=3  hl=3 l= 141 prim: BIT STRING        
  460:d=2  hl=4 l= 332 cons: cont [ 3 ]        
  464:d=3  hl=4 l= 328 cons: SEQUENCE          
  468:d=4  hl=2 l=   9 cons: SEQUENCE          
  470:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
  475:d=5  hl=2 l=   2 prim: OCTET STRING      
  479:d=4  hl=2 l=  17 cons: SEQUENCE          
  481:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Cert Type
  492:d=5  hl=2 l=   4 prim: OCTET STRING      
  498:d=4  hl=2 l=  43 cons: SEQUENCE          
  500:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Comment
  511:d=5  hl=2 l=  30 prim: OCTET STRING      
  543:d=4  hl=2 l=  29 cons: SEQUENCE          
  545:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
  550:d=5  hl=2 l=  22 prim: OCTET STRING      
  574:d=4  hl=3 l= 182 cons: SEQUENCE          
  577:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
  582:d=5  hl=3 l= 174 prim: OCTET STRING      
  759:d=4  hl=2 l=  24 cons: SEQUENCE          
  761:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Issuer Alternative Name
  766:d=5  hl=2 l=  17 prim: OCTET STRING      
  785:d=4  hl=2 l=   9 cons: SEQUENCE          
  787:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
  792:d=5  hl=2 l=   2 prim: OCTET STRING      
  796:d=1  hl=2 l=  13 cons: SEQUENCE          
  798:d=2  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
  809:d=2  hl=2 l=   0 prim: NULL              
  811:d=1  hl=4 l= 513 prim: BIT STRING        

and:

$ openssl asn1parse -in b -inform pem
    0:d=0  hl=4 l=1801 cons: SEQUENCE          
    4:d=1  hl=4 l=1265 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   1 prim: INTEGER           :01
   16:d=2  hl=2 l=  13 cons: SEQUENCE          
   18:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
   29:d=3  hl=2 l=   0 prim: NULL              
   31:d=2  hl=3 l= 137 cons: SEQUENCE          
   34:d=3  hl=2 l=  11 cons: SET              
   36:d=4  hl=2 l=   9 cons: SEQUENCE          
   38:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   43:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
   47:d=3  hl=2 l=  15 cons: SET              
   49:d=4  hl=2 l=  13 cons: SEQUENCE          
   51:d=5  hl=2 l=   3 prim: OBJECT            :localityName
   56:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
   64:d=3  hl=2 l=  47 cons: SET              
   66:d=4  hl=2 l=  45 cons: SEQUENCE          
   68:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   73:d=5  hl=2 l=  38 prim: PRINTABLESTRING   :Candler Insecure Certificate Authority
  113:d=3  hl=2 l=  27 cons: SET              
  115:d=4  hl=2 l=  25 cons: SEQUENCE          
  117:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  122:d=5  hl=2 l=  18 prim: PRINTABLESTRING   :root.ca.linnet.org
  142:d=3  hl=2 l=  27 cons: SET              
  144:d=4  hl=2 l=  25 cons: SEQUENCE          
  146:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  157:d=5  hl=2 l=  12 prim: IA5STRING         :[hidden email]
  171:d=2  hl=2 l=  30 cons: SEQUENCE          
  173:d=3  hl=2 l=  13 prim: UTCTIME           :060227095204Z
  188:d=3  hl=2 l=  13 prim: UTCTIME           :160225095204Z
  203:d=2  hl=3 l= 137 cons: SEQUENCE          
  206:d=3  hl=2 l=  11 cons: SET              
  208:d=4  hl=2 l=   9 cons: SEQUENCE          
  210:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  215:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
  219:d=3  hl=2 l=  15 cons: SET              
  221:d=4  hl=2 l=  13 cons: SEQUENCE          
  223:d=5  hl=2 l=   3 prim: OBJECT            :localityName
  228:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
  236:d=3  hl=2 l=  47 cons: SET              
  238:d=4  hl=2 l=  45 cons: SEQUENCE          
  240:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
  245:d=5  hl=2 l=  38 prim: PRINTABLESTRING   :Candler Insecure Certificate Authority
  285:d=3  hl=2 l=  26 cons: SET              
  287:d=4  hl=2 l=  24 cons: SEQUENCE          
  289:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  294:d=5  hl=2 l=  17 prim: PRINTABLESTRING   :sub.ca.linnet.org
  313:d=3  hl=2 l=  28 cons: SET              
  315:d=4  hl=2 l=  26 cons: SEQUENCE          
  317:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  328:d=5  hl=2 l=  13 prim: IA5STRING         :[hidden email]
  343:d=2  hl=4 l= 546 cons: SEQUENCE          
  347:d=3  hl=2 l=  13 cons: SEQUENCE          
  349:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  360:d=4  hl=2 l=   0 prim: NULL              
  362:d=3  hl=4 l= 527 prim: BIT STRING        
  893:d=2  hl=4 l= 376 cons: cont [ 3 ]        
  897:d=3  hl=4 l= 372 cons: SEQUENCE          
  901:d=4  hl=2 l=  29 cons: SEQUENCE          
  903:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
  908:d=5  hl=2 l=  22 prim: OCTET STRING      
  932:d=4  hl=3 l= 190 cons: SEQUENCE          
  935:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
  940:d=5  hl=3 l= 182 prim: OCTET STRING      
 1125:d=4  hl=2 l=  15 cons: SEQUENCE          
 1127:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 1132:d=5  hl=2 l=   1 prim: BOOLEAN           :255
 1135:d=5  hl=2 l=   5 prim: OCTET STRING      
 1142:d=4  hl=2 l=  17 cons: SEQUENCE          
 1144:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Cert Type
 1155:d=5  hl=2 l=   4 prim: OCTET STRING      
 1161:d=4  hl=2 l=  23 cons: SEQUENCE          
 1163:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Issuer Alternative Name
 1168:d=5  hl=2 l=  16 prim: OCTET STRING      
 1186:d=4  hl=2 l=  43 cons: SEQUENCE          
 1188:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Comment
 1199:d=5  hl=2 l=  30 prim: OCTET STRING      
 1231:d=4  hl=2 l=  24 cons: SEQUENCE          
 1233:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
 1238:d=5  hl=2 l=  17 prim: OCTET STRING      
 1257:d=4  hl=2 l=  14 cons: SEQUENCE          
 1259:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
 1264:d=5  hl=2 l=   1 prim: BOOLEAN           :255
 1267:d=5  hl=2 l=   4 prim: OCTET STRING      
 1273:d=1  hl=2 l=  13 cons: SEQUENCE          
 1275:d=2  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
 1286:d=2  hl=2 l=   0 prim: NULL              
 1288:d=1  hl=4 l= 513 prim: BIT STRING        
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Dr. Stephen Henson
On Mon, Feb 27, 2006, Brian Candler wrote:

> I'm trying to get a client to verify a server certificate signed by a sub-CA
> when the client has only the root CA certificate.
>
> I'm using TinyCA (GUI wrapper around OpenSSL) as the CA. Here's what I've
> done:
>
> 1. Created a root CA (CN=root.ca.linnet.org)
> 2. Created a sub CA under this (CN=sub.ca.linnet.org)
> 3. Created a CSR and signed it by the sub CA
> 4. Installed the certificate in a small server
>
>     #!/bin/sh
>     cd content
>     openssl s_server -cert ../server.example.com-cert.pem \
>       -key ../server.example.com-key.pem \
>       -CApath /etc/ssl/certs \
>       -WWW
>
> 5. Installed the root CA's certificate under /etc/ssl/certs and re-ran
>    c_rehash to incorporate it.
>
> However, when the client connects, it is not presented with a full
> certificate chain back to the root, but just the certificate signed by the
> subCA:
>
>     $ openssl s_client -connect localhost:4433 -CApath /etc/ssl/certs -showcerts
>     ...
>     ---
>     Certificate chain
>      0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com
>        i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/emailAddress=[hidden email]
>     ---
>
> As a result, even though the client has the root certificate available
> (CN=root.ca.linnet.org), it's unable to verify the certificate presented.
>
> Somehow, I need to get the server to present a full certificate chain to the
> client.
>
> I tried appending the sub CA's own certificate (signed by the root CA) to
> server.example.com-cert.pem, but that didn't make any difference. If I
> swapped the two around, so that the sub CA's certificate is first, then
> OpenSSL won't start:
>
> $ ./server.sh
> Using default temp DH parameters
> Enter PEM pass phrase:
> unable to get private key from '../server.example.com-key.pem'
> 86322:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509/x509_cmp.c:389:
>
> Anyway, it's not clear to me whether the certificate generated by TinyCA is
> incomplete, or whether there's some additional configuration required by the
> server to get it to send the chain. I'd be very grateful if someone could
> point me in the right direction.
>
> The certificates and their decoding are attached below.
>
> Regards,
>
> Brian.
>
> Here are the two certificates, which currently are appended together in
> server.example.com-cert.pem, although it seems only the first one is used.
>
[snipped]

Since you didn't include the root CA it isn't possible to say why it isn't
excluded.

I notice the small serial numbers in the certificates and some invalid
extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL
0.9.8 get it from a recent snapshot: the included one is buggy) instead.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Brian Candler
On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote:
> Since you didn't include the root CA it isn't possible to say why it isn't
> excluded.
>
> I notice the small serial numbers in the certificates and some invalid
> extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL
> 0.9.8 get it from a recent snapshot: the included one is buggy) instead.

The root certificate is attached below. I also tried appending this to my
server.example.com-cert.pem (so there were three certificates in all), but
that didn't make a difference.

Is it correct of me simply to concatenate the server certificate together
with the sub-CA certificate and the root certificate? Or should TinyCA have
created a certificate which incorporates the whole chain itself? Or does the
application use some other mechanism to assemble the chain from the
constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to
know what a real certificate at the bottom of a chain should look like.

I think that the small serial numbers are intentional; these are the first
certificates issued by the root CA and the sub CA respectively, and openssl
creates them as newcerts/01.pem. However, I note that the root self-signed
certificate does seem to have a very large serial number.

I can try doing everything from scratch using openssl commands solely, but
TinyCA itself is just a set of perl scripts which call openssl req/ca as
required. Do you think TinyCA is invoking openssl wrongly in this case?
Regards,

Brian.

-----BEGIN CERTIFICATE-----
MIIHAjCCBOqgAwIBAgIJAP5hXQM6l3J+MA0GCSqGSIb3DQEBBAUAMIGJMQswCQYD
VQQGEwJHQjEPMA0GA1UEBxMGTG9uZG9uMS8wLQYDVQQKEyZDYW5kbGVyIEluc2Vj
dXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTEbMBkGA1UEAxMScm9vdC5jYS5saW5u
ZXQub3JnMRswGQYJKoZIhvcNAQkBFgxjYUBsaW5uZXQub2cwHhcNMDYwMjI3MDk0
ODQ1WhcNMTYwMjI1MDk0ODQ1WjCBiTELMAkGA1UEBhMCR0IxDzANBgNVBAcTBkxv
bmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEbMBkGCSqGSIb3DQEJ
ARYMY2FAbGlubmV0Lm9nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
86u5sSM8mxdIhuTOZbOtr2mkUOzjINQTVqIWR7mLmaCNyz5Zvqd2Pu4DjwrRadko
zVrtxlG2C1kwd9zUEB0MaRkrOL6EdaQNxNZ7OIoP+JYPAKzSlwcu6wiIFsYZZ9Zg
QCs150kw9CYfofjsC5NHWetfogJvnKtseqBfQt5Ohl3SGM26/JQpMF0GpJWL/U4L
GBvWsRKZRlTHAAWWv8AAOFPgLEfTgLKvOPNHUxoG+TDH2CtNfQO5DpxacB4WFKPP
5NSmVu5bxWWqalU07J0xuv+KlLRdJZ0ZORLaxq919ezxVCjwVfqv80Y6LzzwgZsz
9kIlWoN+N3U3SA8gVuOcrdUmh/HRIs4YkSjeaqfF0n91YNMwdMvipKmX0OeinujK
eNEvT16JAGjUaveTQulvPkWDhV7evXh1yGv5HFfoIp/N6zGAKBr2uZDtgd6vnXlU
eRLMXAtokbCkB+Rd7el4SBO0ZgeUTA2chZNjtv17mbWZQR0NQsMdYgOO4oc/MEoa
ZwaesMec0iLNtCpSq2TyxikkC0qAcirv/a4Qqbb35DXdSRiXS11A11pDTQdGqKBY
u9RZTTCk2JYkxcLC8DLf2BsK/NBrb+WV24fyLOelbbhBUyQoxvF0vkhO2MdDfjns
yr8UBF6IqYvhPmHTNSx9WJXfkLU2HyI0n7QZ/lvjipsCAwEAAaOCAWkwggFlMB0G
A1UdDgQWBBRc63ElpozI5U1LsApJkx5YAYl3HjCBvgYDVR0jBIG2MIGzgBRc63El
pozI5U1LsApJkx5YAYl3HqGBj6SBjDCBiTELMAkGA1UEBhMCR0IxDzANBgNVBAcT
BkxvbmRvbjEvMC0GA1UEChMmQ2FuZGxlciBJbnNlY3VyZSBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkxGzAZBgNVBAMTEnJvb3QuY2EubGlubmV0Lm9yZzEbMBkGCSqGSIb3
DQEJARYMY2FAbGlubmV0Lm9nggkA/mFdAzqXcn4wDwYDVR0TAQH/BAUwAwEB/zAR
BglghkgBhvhCAQEEBAMCAQYwCQYDVR0SBAIwADArBglghkgBhvhCAQ0EHhYcVGlu
eUNBIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAXBgNVHREEEDAOgQxjYUBsaW5uZXQu
b2cwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4ICAQBwVm4ODxvvF5GU
qrIpPA9IF1JY2jIwgK9E3tGNmoULAUKPyx4hqHpma/h88c8ZIDZ1/CPfnIgC4doE
htSdBlErZ9aqj3ZRfhVeVoeHdEHp+xC+qHxAVeFgaSm6sa6NM2Obj1h+YECw+YeO
Vm826GT3/Pw40BI5U0UmIbeIivf+i3zGttQruo/JmE2XM+gOCjeKu1v4T189DcAm
Dlrc24K06CMwI/ZpTuexEWtWC5W3ASaxO14Liq8iDgd2x1y61zlyEYCITkXYWwos
wmlrbIc77NfIzO/fFgy+bOaJCP7R4Uz5L5zdqbmqdvhgeREJJTNX2CDVxDvaDVy2
bJQh8NMnPIAfP5kBJ9Ps6o646HwLwzD4LNPsA10uOBrfaxImT7S+vDaD5y0M0jz9
Tkxj/ry6UB78CNeRyl9SBmM+lCFAISxlZJt6VR85EVxD50PI5DjeK+xYAd8CKimr
v5vbycDQhFnd7dztIyAVOcTm/77PpYVqc1TJxPBKPPa3p/ex6H83lD9kKgip1smQ
G65x4v9jISrTpL8Cd4ERcuJmVBNVwCaKJxS5xjzhNs76gW3LeG0uxYADFMtmK2s3
H2XagAOn+pfPFUOA6CA+YaZzWcv0qL9PrRgoW4safcsCGAHxkop/9Ue1PvWMPGWc
kmnUshRcY8xjRvacwBQwu5YHc/4DDA==
-----END CERTIFICATE-----

    0:d=0  hl=4 l=1794 cons: SEQUENCE          
    4:d=1  hl=4 l=1258 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   9 prim: INTEGER           :FE615D033A97727E
   24:d=2  hl=2 l=  13 cons: SEQUENCE          
   26:d=3  hl=2 l=   9 prim: OBJECT            :md5WithRSAEncryption
   37:d=3  hl=2 l=   0 prim: NULL              
   39:d=2  hl=3 l= 137 cons: SEQUENCE          
   42:d=3  hl=2 l=  11 cons: SET              
   44:d=4  hl=2 l=   9 cons: SEQUENCE          
   46:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   51:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
   55:d=3  hl=2 l=  15 cons: SET              
   57:d=4  hl=2 l=  13 cons: SEQUENCE          
   59:d=5  hl=2 l=   3 prim: OBJECT            :localityName
   64:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
   72:d=3  hl=2 l=  47 cons: SET              
   74:d=4  hl=2 l=  45 cons: SEQUENCE          
   76:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   81:d=5  hl=2 l=  38 prim: PRINTABLESTRING   :Candler Insecure Certificate Authority
  121:d=3  hl=2 l=  27 cons: SET              
  123:d=4  hl=2 l=  25 cons: SEQUENCE          
  125:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  130:d=5  hl=2 l=  18 prim: PRINTABLESTRING   :root.ca.linnet.org
  150:d=3  hl=2 l=  27 cons: SET              
  152:d=4  hl=2 l=  25 cons: SEQUENCE          
  154:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  165:d=5  hl=2 l=  12 prim: IA5STRING         :[hidden email]
  179:d=2  hl=2 l=  30 cons: SEQUENCE          
  181:d=3  hl=2 l=  13 prim: UTCTIME           :060227094845Z
  196:d=3  hl=2 l=  13 prim: UTCTIME           :160225094845Z
  211:d=2  hl=3 l= 137 cons: SEQUENCE          
  214:d=3  hl=2 l=  11 cons: SET              
  216:d=4  hl=2 l=   9 cons: SEQUENCE          
  218:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  223:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :GB
  227:d=3  hl=2 l=  15 cons: SET              
  229:d=4  hl=2 l=  13 cons: SEQUENCE          
  231:d=5  hl=2 l=   3 prim: OBJECT            :localityName
  236:d=5  hl=2 l=   6 prim: PRINTABLESTRING   :London
  244:d=3  hl=2 l=  47 cons: SET              
  246:d=4  hl=2 l=  45 cons: SEQUENCE          
  248:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
  253:d=5  hl=2 l=  38 prim: PRINTABLESTRING   :Candler Insecure Certificate Authority
  293:d=3  hl=2 l=  27 cons: SET              
  295:d=4  hl=2 l=  25 cons: SEQUENCE          
  297:d=5  hl=2 l=   3 prim: OBJECT            :commonName
  302:d=5  hl=2 l=  18 prim: PRINTABLESTRING   :root.ca.linnet.org
  322:d=3  hl=2 l=  27 cons: SET              
  324:d=4  hl=2 l=  25 cons: SEQUENCE          
  326:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
  337:d=5  hl=2 l=  12 prim: IA5STRING         :[hidden email]
  351:d=2  hl=4 l= 546 cons: SEQUENCE          
  355:d=3  hl=2 l=  13 cons: SEQUENCE          
  357:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
  368:d=4  hl=2 l=   0 prim: NULL              
  370:d=3  hl=4 l= 527 prim: BIT STRING        
  901:d=2  hl=4 l= 361 cons: cont [ 3 ]        
  905:d=3  hl=4 l= 357 cons: SEQUENCE          
  909:d=4  hl=2 l=  29 cons: SEQUENCE          
  911:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
  916:d=5  hl=2 l=  22 prim: OCTET STRING      
  940:d=4  hl=3 l= 190 cons: SEQUENCE          
  943:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
  948:d=5  hl=3 l= 182 prim: OCTET STRING      
 1133:d=4  hl=2 l=  15 cons: SEQUENCE          
 1135:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 1140:d=5  hl=2 l=   1 prim: BOOLEAN           :255
 1143:d=5  hl=2 l=   5 prim: OCTET STRING      
 1150:d=4  hl=2 l=  17 cons: SEQUENCE          
 1152:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Cert Type
 1163:d=5  hl=2 l=   4 prim: OCTET STRING      
 1169:d=4  hl=2 l=   9 cons: SEQUENCE          
 1171:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Issuer Alternative Name
 1176:d=5  hl=2 l=   2 prim: OCTET STRING      
 1180:d=4  hl=2 l=  43 cons: SEQUENCE          
 1182:d=5  hl=2 l=   9 prim: OBJECT            :Netscape Comment
 1193:d=5  hl=2 l=  30 prim: OCTET STRING      
 1225:d=4  hl=2 l=  23 cons: SEQUENCE          
 1227:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
 1232:d=5  hl=2 l=  16 prim: OCTET STRING      
 1250:d=4  hl=2 l=  14 cons: SEQUENCE          
 1252:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
 1257:d=5  hl=2 l=   1 prim: BOOLEAN           :255
 1260:d=5  hl=2 l=   4 prim: OCTET STRING      
 1266:d=1  hl=2 l=  13 cons: SEQUENCE          
 1268:d=2  hl=2 l=   9 prim: OBJECT            :md5WithRSAEncryption
 1279:d=2  hl=2 l=   0 prim: NULL              
 1281:d=1  hl=4 l= 513 prim: BIT STRING        
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Dr. Stephen Henson
On Mon, Feb 27, 2006, Brian Candler wrote:

> On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote:
> > Since you didn't include the root CA it isn't possible to say why it isn't
> > excluded.
> >
> > I notice the small serial numbers in the certificates and some invalid
> > extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL
> > 0.9.8 get it from a recent snapshot: the included one is buggy) instead.
>
> The root certificate is attached below. I also tried appending this to my
> server.example.com-cert.pem (so there were three certificates in all), but
> that didn't make a difference.
>

Have you tried placing the sub CA in /etc/ssl/certs and running c_rehash on
that directory?

> Is it correct of me simply to concatenate the server certificate together
> with the sub-CA certificate and the root certificate? Or should TinyCA have
> created a certificate which incorporates the whole chain itself? Or does the
> application use some other mechanism to assemble the chain from the
> constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to
> know what a real certificate at the bottom of a chain should look like.
>

It needs to have the whole chain visible somehow. Placing the subCA and root
CA in the trusted directory is one way. Concatenating them into a single file
and pointing to that using -CAfile is another.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Brian Candler
On Mon, Feb 27, 2006 at 08:05:59PM +0100, Dr. Stephen Henson wrote:

> On Mon, Feb 27, 2006, Brian Candler wrote:
>
> > On Mon, Feb 27, 2006 at 01:41:33PM +0100, Dr. Stephen Henson wrote:
> > > Since you didn't include the root CA it isn't possible to say why it isn't
> > > excluded.
> > >
> > > I notice the small serial numbers in the certificates and some invalid
> > > extensions in there. I'd suggest using the CA.pl script (if you use OpenSSL
> > > 0.9.8 get it from a recent snapshot: the included one is buggy) instead.
> >
> > The root certificate is attached below. I also tried appending this to my
> > server.example.com-cert.pem (so there were three certificates in all), but
> > that didn't make a difference.
> >
>
> Have you tried placing the sub CA in /etc/ssl/certs and running c_rehash on
> that directory?

I hadn't, because I thought that would invalidate what I'm trying to do.
Clearly, if I distribute the sub-CA's certificate to all the clients, then
they will be able to validate it anyway.

But I hadn't thought that perhaps the *server* side still needs to be able
to pick up those certificates from there...

[Test]

Yep, if I do that, the server does indeed hand out the chain.

> > Is it correct of me simply to concatenate the server certificate together
> > with the sub-CA certificate and the root certificate? Or should TinyCA have
> > created a certificate which incorporates the whole chain itself? Or does the
> > application use some other mechanism to assemble the chain from the
> > constituent certificates? I'm afraid I'm not sufficiently PKCS#7-savvy to
> > know what a real certificate at the bottom of a chain should look like.
> >
>
> It needs to have the whole chain visible somehow. Placing the subCA and root
> CA in the trusted directory is one way. Concatenating them into a single file
> and pointing to that using -CAfile is another.

Ah. I had just used -cert ../server.example.com-cert.pem (where this file
contains all the certificates). So now I've added -CAfile as well, pointing
to the same file:

#!/bin/sh
cd content
openssl s_server -cert ../server.example.com-cert.pem \
  -CAfile ../server.example.com-cert.pem \
  -key ../server.example.com-key.pem \
  -WWW

And it works. I've removed the sub-CA certificate and its symlink from
/etc/ssl/certs, but the client can still verify the chain:

$ openssl s_client -connect localhost:4433 -showcerts -CApath /etc/ssl/certs
CONNECTED(00000003)
depth=2 /C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/emailAddress=[hidden email]
verify return:1
depth=1 /C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/emailAddress=[hidden email]
verify return:1
depth=0 /C=GB/L=London/O=Test server certificate/CN=server.example.com
verify return:1
---
Certificate chain
 0 s:/C=GB/L=London/O=Test server certificate/CN=server.example.com
   i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/emailAddress=[hidden email]
...
 1 s:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=sub.ca.linnet.org/emailAddress=[hidden email]
   i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/emailAddress=[hidden email]
...
 2 s:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/emailAddress=[hidden email]
   i:/C=GB/L=London/O=Candler Insecure Certificate Authority/CN=root.ca.linnet.org/emailAddress=[hidden email]
...
    Verify return code: 0 (ok)

That's great. Many thanks for pointing me in the right direction on this
one.

Regards,

Brian.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Brian Candler
On Mon, Feb 27, 2006 at 07:36:16PM +0000, Brian Candler wrote:

> Ah. I had just used -cert ../server.example.com-cert.pem (where this file
> contains all the certificates). So now I've added -CAfile as well, pointing
> to the same file:
>
> #!/bin/sh
> cd content
> openssl s_server -cert ../server.example.com-cert.pem \
>   -CAfile ../server.example.com-cert.pem \
>   -key ../server.example.com-key.pem \
>   -WWW
>
> And it works. I've removed the sub-CA certificate and its symlink from
> /etc/ssl/certs, but the client can still verify the chain:

As a follow-up for the benefit of the list archive: to get this to work in
Apache+mod_ssl I just had to uncomment

SSLCertificateChainFile /usr/local/etc/apache/ssl.crt/ca.crt

from httpd.conf, and point it at a file containing the sub-CA's certificate
(signed by the root CA) and the root CA's own self-signed certificate.

Regards,

Brian.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Kyle Hamilton
The only certificates that must be sent are the server identification
and the certs up to (but not including) the trust anchor.  (Since the
client already has the trust anchor, it will verify against its local
copy of the root CA, not the copy of the root CA that came from the
connection.)

Sending the extra certificate doesn't hurt, though.

-Kyle H

On 2/27/06, Brian Candler <[hidden email]> wrote:

> On Mon, Feb 27, 2006 at 07:36:16PM +0000, Brian Candler wrote:
> > Ah. I had just used -cert ../server.example.com-cert.pem (where this file
> > contains all the certificates). So now I've added -CAfile as well, pointing
> > to the same file:
> >
> > #!/bin/sh
> > cd content
> > openssl s_server -cert ../server.example.com-cert.pem \
> >   -CAfile ../server.example.com-cert.pem \
> >   -key ../server.example.com-key.pem \
> >   -WWW
> >
> > And it works. I've removed the sub-CA certificate and its symlink from
> > /etc/ssl/certs, but the client can still verify the chain:
>
> As a follow-up for the benefit of the list archive: to get this to work in
> Apache+mod_ssl I just had to uncomment
>
> SSLCertificateChainFile /usr/local/etc/apache/ssl.crt/ca.crt
>
> from httpd.conf, and point it at a file containing the sub-CA's certificate
> (signed by the root CA) and the root CA's own self-signed certificate.
>
> Regards,
>
> Brian.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Alain Damiral
Hi,

This question might be slightly silly and out of place but this
conversation brought it up to me. I don't remember seeing the answer...

Is it possible to send several chains, each rooted by a different CA ?
And then let the client determine if he trusts one of those CAs.

Cheers,

- Alain

Kyle Hamilton wrote:

>The only certificates that must be sent are the server identification
>and the certs up to (but not including) the trust anchor.  (Since the
>client already has the trust anchor, it will verify against its local
>copy of the root CA, not the copy of the root CA that came from the
>connection.)
>
>Sending the extra certificate doesn't hurt, though.
>
>-Kyle H
>
>On 2/27/06, Brian Candler <[hidden email]> wrote:
>  
>
>>On Mon, Feb 27, 2006 at 07:36:16PM +0000, Brian Candler wrote:
>>    
>>
>>>Ah. I had just used -cert ../server.example.com-cert.pem (where this file
>>>contains all the certificates). So now I've added -CAfile as well, pointing
>>>to the same file:
>>>
>>>#!/bin/sh
>>>cd content
>>>openssl s_server -cert ../server.example.com-cert.pem \
>>>  -CAfile ../server.example.com-cert.pem \
>>>  -key ../server.example.com-key.pem \
>>>  -WWW
>>>
>>>And it works. I've removed the sub-CA certificate and its symlink from
>>>/etc/ssl/certs, but the client can still verify the chain:
>>>      
>>>
>>As a follow-up for the benefit of the list archive: to get this to work in
>>Apache+mod_ssl I just had to uncomment
>>
>>SSLCertificateChainFile /usr/local/etc/apache/ssl.crt/ca.crt
>>
>>from httpd.conf, and point it at a file containing the sub-CA's certificate
>>(signed by the root CA) and the root CA's own self-signed certificate.
>>
>>Regards,
>>
>>Brian.
>>______________________________________________________________________
>>OpenSSL Project                                 http://www.openssl.org
>>User Support Mailing List                    [hidden email]
>>Automated List Manager                           [hidden email]
>>
>>    
>>
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [hidden email]
>Automated List Manager                           [hidden email]
>  
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Installing a certificate chain

Kyle Hamilton
Actually, there's a paper that was pointed out to me not too long ago
(by Philipp G├╝hring of CAcert.org) -- it /should/ be possible, however
there's a severe lack of support in the current implementations.

http://www.dfn-pca.de/bibliothek/reports/pki-linking/report-linking-final-1.0.2.pdf
(CC:AT-NC-SA)

I would like to see support made much more available.

-Kyle H

On 2/28/06, Alain Damiral <[hidden email]> wrote:

> Hi,
>
> This question might be slightly silly and out of place but this
> conversation brought it up to me. I don't remember seeing the answer...
>
> Is it possible to send several chains, each rooted by a different CA ?
> And then let the client determine if he trusts one of those CAs.
>
> Cheers,
>
> - Alain
>
> Kyle Hamilton wrote:
>
> >The only certificates that must be sent are the server identification
> >and the certs up to (but not including) the trust anchor.  (Since the
> >client already has the trust anchor, it will verify against its local
> >copy of the root CA, not the copy of the root CA that came from the
> >connection.)
> >
> >Sending the extra certificate doesn't hurt, though.
> >
> >-Kyle H
> >
> >On 2/27/06, Brian Candler <[hidden email]> wrote:
> >
> >
> >>On Mon, Feb 27, 2006 at 07:36:16PM +0000, Brian Candler wrote:
> >>
> >>
> >>>Ah. I had just used -cert ../server.example.com-cert.pem (where this file
> >>>contains all the certificates). So now I've added -CAfile as well, pointing
> >>>to the same file:
> >>>
> >>>#!/bin/sh
> >>>cd content
> >>>openssl s_server -cert ../server.example.com-cert.pem \
> >>>  -CAfile ../server.example.com-cert.pem \
> >>>  -key ../server.example.com-key.pem \
> >>>  -WWW
> >>>
> >>>And it works. I've removed the sub-CA certificate and its symlink from
> >>>/etc/ssl/certs, but the client can still verify the chain:
> >>>
> >>>
> >>As a follow-up for the benefit of the list archive: to get this to work in
> >>Apache+mod_ssl I just had to uncomment
> >>
> >>SSLCertificateChainFile /usr/local/etc/apache/ssl.crt/ca.crt
> >>
> >>from httpd.conf, and point it at a file containing the sub-CA's certificate
> >>(signed by the root CA) and the root CA's own self-signed certificate.
> >>
> >>Regards,
> >>
> >>Brian.
> >>______________________________________________________________________
> >>OpenSSL Project                                 http://www.openssl.org
> >>User Support Mailing List                    [hidden email]
> >>Automated List Manager                           [hidden email]
> >>
> >>
> >>
> >______________________________________________________________________
> >OpenSSL Project                                 http://www.openssl.org
> >User Support Mailing List                    [hidden email]
> >Automated List Manager                           [hidden email]
> >
> >
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]