Apache certificate chain is not being sent

However, when I check with a browser, I see only the server certificate and does not contain the intermediary or CA certificates. The same is confirmed with both ssllabs and sslshopper.

Is there an option I'm missing that ensures that you're publishing the entire chain and not just the server's certificate?

asked Apr 7, 2016 at 13:20 scuba_mike scuba_mike 221 2 2 silver badges 10 10 bronze badges You can’t really see that in your browser. Did you try one of the sites indicated? Commented Apr 7, 2016 at 13:23

Instructions look fine. Make sure the certificates themselves are correct though. (Maybe your cert was issued by a different intermediate than you're trying to bundle?) Try also ssl-tools.net to check the chain.

Commented Apr 7, 2016 at 13:31

DanielB, yes. The same has been confirmed by both ssllabs.com and sslshopper.com grawity, that was my thinking too but I have checked the Subject and Issuer.

Commented Apr 7, 2016 at 14:24

Additionally, I ran the following command: openssl verify -CAfile ca.pem -untrusted intermediary.pem apache.pem and this return OK.

Commented Apr 7, 2016 at 14:47

That doesn’t test your server configuration in any way, though. Since you have OpenSSL available, things are quite easy. I’ll write an answer soon.

Commented Apr 7, 2016 at 16:47

2 Answers 2

If you have OpenSSL at your disposal, verifying this is exceedingly easy:

cat /dev/null | openssl s_client -showcerts -servername example.com -connect example.com:443

I’ll explain the components:

cat /dev/null : openssl s_client works much like telnet . It establishes the connection and you can then interact with it. When openssl encounters EOF in the input stream, the connection is closed. cat /dev/null immediately results in EOF. Alternatively, you can use Ctrl D to issue EOF on the terminal.
openssl s_client : “SSL/TLS client program”
-showcerts : Show certificate blobs in PEM format. Only shows server certificate otherwise.
-servername example.com : Set server name for SNI. Required when doing HTTPS name-based vhosts.
-connect example.com:443 : Connect to example.com at port 443 , the standard HTTPS port.

This results in something like that:

$ cat /dev/null | openssl s_client -showcerts -servername inbox.google.com -connect inbox.google.com:443 CONNECTED(00000003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 -----BEGIN CERTIFICATE----- snip -----END CERTIFICATE----- 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA -----BEGIN CERTIFICATE----- snip -----END CERTIFICATE----- 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority -----BEGIN CERTIFICATE----- snip -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3767 bytes and written 469 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 1B47CE2ADB10CE410C8048C3AAEF7CEF1B2B76C6D2DF5EDE78FE015A6DA44207 Session-ID-ctx: Master-Key: E9AE458F6D72D507F422DA2340C7345AC6EDB087278E62A5FDA754897EC6BDF5C336AFBF6B88554E358C675A3545B724 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: snip Start Time: 1460049698 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE

I used a Google domain here because it has a deeper certificate chain than example.com . The certificate here has “Subject Alternate Names” and as such is also valid for inbox.google.com .

An incorrectly configured server would skip the intermediary certificate, called “Google Internet Authority G2” here. The Equifax certificate is sort-of redundant because GeoTrust is an established CA that’s directly trusted in your browser.