Why does curl need both root and intermediate certificates in order to securely connect to an HTTP server?

Question

I have created a root certificate, an intermediate certificate, and a server certificate:

root (ca.cert.pem)
|
+---intermediate (intermediate/certs/intermediate.cert.pem)
    |
    +---www.example.com
        ↳ certificate: (intermediate/certs/www.example.com.cert.pem)
        ↳ private key: (intermediate/private/www.example.com.key.pem)

I use the private key and public certificate for www.example.com to create an HTTPS server using Node:

var tls = require('tls');
var fs = require('fs');

var options = {
  key: fs.readFileSync('intermediate/private/www.example.com.key.pem'),
  cert: fs.readFileSync('intermediate/certs/www.example.com.cert.pem')
};

tls.createServer(options, function (s) {
  s.write("welcome!\n");
  s.pipe(s);
}).listen(8000);

I want to verify that if a client has access to the root certificate (ca.cert.pem) it can successfully send a secure request to https://www.example.com:8000.

If I try:

$ curl -v --cacert certs/ca.cert.pem https://www.example.com:8000

It fails with an error message:

* Rebuilt URL to: https://www.example.com:8000/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to www.example.com (127.0.0.1) port 8000 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /certs/ca.cert.pem
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, no overlap, use HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

However if I create a certificate chain:

$ cat intermediate/certs/intermediate.cert.pem \
      certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem

And use that as curl's --cacert, everything works as expected:

$ curl -v --cacert intermediate/certs/ca-chain.cert.pem   https://www.example.com:8000
* Rebuilt URL to: https://www.example.com:8000/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to www.example.com (127.0.0.1) port 8000 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /intermediate/certs/ca-chain.cert.pem
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, no overlap, use HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Unknown (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=AU; ST=Victoria; L=Melbourne; O=ACME; OU=ACME Web; CN=www.example.com; [email protected]
*  start date: Nov 12 11:32:59 2018 GMT
*  expire date: Nov 22 11:32:59 2019 GMT
*  common name: www.example.com (matched)
*  issuer: C=AU; ST=Victoria; O=ACME; OU=ACME Certificate Authority; CN=ACME Intermediate CA; [email protected]
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www.example.com:8000
> User-Agent: curl/7.58.0
> Accept: */*
> 
welcome!
GET / HTTP/1.1
Host: www.example.com:8000
User-Agent: curl/7.58.0
Accept: */*

If I am not wrong, similar to browsers, curl should only need the root certificate to verify the signature of the SSL certificate for www.example.com. So why does curl expect both of the root and intermediate certificates in order to be able to verify that it is indeed communicating with the correct server?

The PEM files

Here is the content of the PEM files used in this setup (throw away, unencrypted PEM files):

`ca.cert.pem`

`intermediate.cert.pem`

`www.example.com.cert.pem`

`www.example.com.key.pem`

Community · Accepted Answer · 2021-10-07 07:59:29Z

6

(0) this isn't really about crypto and would probably be better on security.SX, which has lots of Qs about certificate chaining and HTTPS browser and server usage, but ...

(1) while AIA is used more nowadays than in the past and can be an acceptable workaround, the official, standard solution is that the server must send the chain including intermediate cert(s) up to but not necessarily including the root cert, see https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2 et pred (note: TLS1.3 rfc8446 changes this slightly) or the ursine epic https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work at the heading Certificates and Authentication, and ...

(2) there are numerous Qs on several Stacks about how to configure various servers to send the cert chain as required; for nodejs start with
https://stackoverflow.com/questions/19104215/node-js-express-js-chain-certificate-not-working
https://stackoverflow.com/questions/16224064/running-ssl-node-js-server-with-godaddy-gd-bundle-crt
https://stackoverflow.com/questions/32777760/how-to-fix-missing-an-intermediate-chain-certificate-in-nodejs

edited Oct 7, 2021 at 7:59

CommunityBot

1

answered Nov 13, 2018 at 10:11

dave_thompson_085

6,4741 gold badge21 silver badges24 bronze badges

$\begingroup$ I thought about moving this to Server Fault, Superuser, or the Security SX too. If you or anybody else can move it, I would be more than happy. In the end I modified my intermediate CA's OpenSSL config file and added authorityInfoAccess = caIssuers;URI:http://certs.example.com:8000/ca.cer and it resolved the issue. Before reading data from https://www.example.com, the client first sends a request to http://certs.example.com:8000/ca.cer and retrieves the intermediate CA. If I add my root CA to the client's trust store, it then succeeds in verifying the chain. $\endgroup$
– Behrang Saeedzadeh
Commented Nov 13, 2018 at 10:33
$\begingroup$ @Behrang: I saw your edit before review killed it, but didn't approve because it's a very different answer: I noted AIA as an alternative but only described serving the chain, while your approach is AIA only (and not the chain). I suggest you post it as a separate answer, so people have the chance to vote or comment separately if they want. (In case you don't know, Stack definitely permits a 'self-answer' by the question asker. although you may have to wait to accept it.) $\endgroup$
– dave_thompson_085
Commented Nov 16, 2018 at 6:24
$\begingroup$ No worries Dave! All good! 😃 $\endgroup$
– Behrang Saeedzadeh
Commented Nov 16, 2018 at 9:41

Add a comment |

Swashbuckler · Accepted Answer · 2018-11-12 14:17:09Z

1

If I am not wrong, similar to browsers, curl should only need the root certificate to verify the signature of the SSL certificate for www.example.com

You are wrong. Per the Wikipedia article on certificate chain validation (and there are literally dozens of other similar pages on the web):

the following steps are performed for each certificate in the path, starting from the trust anchor. If any check fails on any certificate, the algorithm terminates and path validation fails.

It then goes on to list a number of steps needed for verification. The point is that the entire chain must be verified and that can only be done if the entire chain is present on the system. There is no way to retrieve from an online source the certificate in the chain during the verification process.

answered Nov 12, 2018 at 14:17

Swashbuckler

2,11810 silver badges8 bronze badges

$\begingroup$ From the Wikipedia page: "For example, in a hierarchical PKI, a certificate chain starting with a web server certificate might lead to a small CA, then to an intermediate CA, then to a large CA whose trust anchor is present in the relying party's web browser.". Here's another answer on the Security Stack Exchange: "Browsers & OS's only store root certificates, not intermediate certs.". So your answer is wrong. $\endgroup$
– Behrang Saeedzadeh
Commented Nov 12, 2018 at 15:26
$\begingroup$ Yes, for certificate validation, the whole chain needs to be traversed. But browsers only store root certificates. The question is: what is missing in my server configuration that does not allow curl to verify the whole chain? It most likely has something to do with Authority Information Access, which is what I am going to look at next. $\endgroup$
– Behrang Saeedzadeh
Commented Nov 12, 2018 at 15:33
$\begingroup$ In my experience, browsers do cache intermediate certificates, so if half your servers are set up with proper chains, you can often get away with only sending the entity certificate -- Firefox will be happy because it's seen the intermediate before, but curl won't because it doesn't have a cache. $\endgroup$
– LHMathies
Commented Jul 23 at 8:26

Add a comment |

Stack Exchange Network

Why does curl need both root and intermediate certificates in order to securely connect to an HTTP server?

The PEM files

`ca.cert.pem`

`intermediate.cert.pem`

`www.example.com.cert.pem`

`www.example.com.key.pem`

2 Answers 2

Your Answer

Not the answer you're looking for? Browse other questions tagged
tls
certificates
or ask your own question.

Hot Network Questions

Why does curl need both root and intermediate certificates in order to securely connect to an HTTP server?

The PEM files

ca.cert.pem

intermediate.cert.pem

www.example.com.cert.pem

www.example.com.key.pem

2 Answers 2

Your Answer

Sign up or log in

Post as a guest

Not the answer you're looking for? Browse other questions tagged tlscertificates or ask your own question.

Related

Hot Network Questions

`ca.cert.pem`

`intermediate.cert.pem`

`www.example.com.cert.pem`

`www.example.com.key.pem`

Not the answer you're looking for? Browse other questions tagged
tls
certificates
or ask your own question.