Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Here only certificates 0 and 2 need to be served. Certificate 1 is a duplicate of certificate 0 and is redundant, and certificate 3 is a root which is already either trusted or not by the browser (if the browser trusts it, it already has a copy and doesn’t need a new copy; if it doesn’t trust it, being given a copy won’t convince it to trust it).
Looks like you are serving a self signed DST Root CA X3 - SHA1 with RSA that can be removed from your server configuration. That in combination with some weak ciphers are probably the reason your not getting a higher score when you test your site. You’ll certainly be more secure if you follow guidelines provided here: https://mozilla.github.io/server-side-tls/ssl-config-generator/ … This configurator will show you how to “make it right”.
Regarding my Apache configuration (/Library/Server/Web/Config/apache2/Sites) the VirtualHosts file points to three certs:
SSLCertificateFile “/etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.cert.pem”
SSLCertificateKeyFile “/etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.key.pem”
SSLCertificateChainFile “/etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.chain.pem”
Not sure what is within those certs or how to change them to remove unnecessary or redundant info. I am using a pretty basic setup from a clean install of Certbot.
What Certbot command did you use? Those files in /etc/certificates wouldn’t have been directly created like that by Certbot itself—Certbot never uses a naming scheme like that.
You can see the contents of the cert or chain file with openssl x509 -text -noout -in followed by the filename (although I think if it contains multiple certificates, only the first one in the file will be parsed).
I created the certificates using Certbot with the following: sudo certbot -i apache -a webroot -w /Library/Server/Web/Data/Sites/Default -d tuvock.serverpit.com
this created three PEM files: /etc/letsencrypt/live/tuvock.serverpit.com
privkey.pem
cert.pem
fullchain.pem
I then imported the certs into Server app creating the private and two certificates above. My configuration would not take fullchain, so I used cert and privkey. I even reproduced the result using a virtual machine running MacOS 10.13. I did not encounter an errors.
I do not see any extra or redundant info in these certificates. Somewhere Server is getting these redundant certificates with the same common name.
Maybe the server application created the PEM files that Apache is using during its import procedure? Could you post the contents of /etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.cert.pem and /etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.chain.pem here? (Please don’t post the key file, because it’s your private key!)
openssl x509 -text -noout -in /etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:0e:4d:01:d0:a6:80:d3:8f:fb:d9:8b:f5:e6:8f:ac:55:ee
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: May 5 02:35:50 2018 GMT
Not After : Aug 3 02:35:50 2018 GMT
Subject: CN=tuvock.serverpit.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:73:47:db:28:d5:59:a1:5f:82:71:a8:57:4e:
ec:a5:97:b1:59:f4:7d:28:3f:1e:c5:b2:0d:e8:78:
3c:11:33:45:5c:8b:fd:a6:27:53:a5:d8:da:8b:7c:
11:da:f1:8c:6e:f4:98:3b:21:a8:2d:ca:4e:8c:9f:
40:8e:58:ce:86:3c:8e:34:5c:4d:d7:f5:29:72:d1:
41:bb:22:47:14:3d:4b:50:21:a1:89:2d:51:90:04:
f3:8d:39:43:91:eb:b2:2a:78:56:17:ec:6e:e8:2b:
c3:a7:d6:71:e4:0f:8e:32:4a:6e:42:2f:e7:6b:15:
29:9c:de:66:ad:a4:f7:d0:40:cd:26:86:a4:2a:4e:
ab:e1:35:d8:a1:84:bc:4e:14:44:5e:be:bd:03:3b:
7f:35:e6:a4:23:1a:24:44:b0:23:71:8d:4a:c8:46:
da:5c:e2:fd:03:6d:69:a0:d0:3f:f6:c0:9c:0d:3f:
8a:6c:98:f9:11:2f:e8:d7:82:0c:be:35:1e:ca:d4:
1f:a4:9e:55:5c:f1:11:37:3f:f7:81:68:3f:c7:5d:
69:c2:33:14:87:1d:be:94:78:d2:bb:78:09:64:dd:
d5:23:a8:ae:fd:a7:e3:15:68:a3:ca:3d:ae:59:39:
07:16:c5:ed:61:48:18:3a:3a:02:3c:0d:28:a6:14:
81:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
E3:F5:18:E5:25:CA:F8:2D:24:65:4A:25:19:6C:E1:4E:F4:C2:EF:28
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:tuvock.serverpit.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
1.3.6.1.4.1.11129.2.4.2:
......w.U.....6.J...W<S...8xp%../..........c.^.......H0F.!.......x.`(.......5.~.8_.b._F..5J.!......QGo.o.4.........yqQ1...G....v.)<Q.T.9e..P.X...o.Xz)r......EG.x...c.^.......G0E.!..........$[.k.N.\....e.r.N1(H.*.. ]../#./.A.......-.......Y.....e.
Signature Algorithm: sha256WithRSAEncryption
07:e1:a7:7d:a2:94:4c:b0:7e:bc:3a:5f:d9:59:01:e0:e0:ea:
73:b4:11:a3:2f:47:d2:18:56:c2:f5:de:fb:bb:61:19:06:e7:
2a:c5:d2:20:14:33:f9:7e:c8:bb:7a:5f:61:08:1c:26:f3:bd:
71:6f:11:08:f0:6d:60:b1:85:bc:b2:0c:ad:0a:91:38:08:d9:
3f:b6:75:d4:8b:2b:29:f9:4b:7f:f4:2a:d9:6e:42:57:db:72:
9a:dc:a4:a7:22:2c:66:ad:e3:5c:13:6e:be:1c:d0:6a:15:04:
28:07:e6:6d:35:16:cb:65:55:db:8a:10:5f:d7:c6:d5:45:ea:
39:81:d6:2f:e3:c3:0a:e1:82:98:38:d0:6f:14:11:b9:17:f1:
f6:5d:0f:6e:ee:7d:9f:e9:5e:d9:5b:0f:f7:a8:da:ed:6d:a8:
8f:84:cc:05:fb:85:f4:6f:33:12:e9:7e:7a:32:88:47:a0:59:
2a:01:e5:d9:02:50:a0:8e:41:1a:a5:6d:c9:25:78:d0:7f:9e:
d1:c5:60:d6:6d:12:f3:d9:12:0f:a6:75:be:d4:43:89:23:c3:
e5:8d:a4:af:1d:a0:6e:73:5d:db:5d:f2:03:80:76:45:56:e4:
8c:16:40:f9:31:61:87:3a:93:2f:af:6d:b8:b9:66:41:0c:3d:
f9:37:1e:a0
openssl x509 -text -noout -in /etc/certificates/tuvock.serverpit.com.B226B8ED40039D61213D3B1541F1BDF30BA5B694.chain.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:0e:4d:01:d0:a6:80:d3:8f:fb:d9:8b:f5:e6:8f:ac:55:ee
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: May 5 02:35:50 2018 GMT
Not After : Aug 3 02:35:50 2018 GMT
Subject: CN=tuvock.serverpit.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:73:47:db:28:d5:59:a1:5f:82:71:a8:57:4e:
ec:a5:97:b1:59:f4:7d:28:3f:1e:c5:b2:0d:e8:78:
3c:11:33:45:5c:8b:fd:a6:27:53:a5:d8:da:8b:7c:
11:da:f1:8c:6e:f4:98:3b:21:a8:2d:ca:4e:8c:9f:
40:8e:58:ce:86:3c:8e:34:5c:4d:d7:f5:29:72:d1:
41:bb:22:47:14:3d:4b:50:21:a1:89:2d:51:90:04:
f3:8d:39:43:91:eb:b2:2a:78:56:17:ec:6e:e8:2b:
c3:a7:d6:71:e4:0f:8e:32:4a:6e:42:2f:e7:6b:15:
29:9c:de:66:ad:a4:f7:d0:40:cd:26:86:a4:2a:4e:
ab:e1:35:d8:a1:84:bc:4e:14:44:5e:be:bd:03:3b:
7f:35:e6:a4:23:1a:24:44:b0:23:71:8d:4a:c8:46:
da:5c:e2:fd:03:6d:69:a0:d0:3f:f6:c0:9c:0d:3f:
8a:6c:98:f9:11:2f:e8:d7:82:0c:be:35:1e:ca:d4:
1f:a4:9e:55:5c:f1:11:37:3f:f7:81:68:3f:c7:5d:
69:c2:33:14:87:1d:be:94:78:d2:bb:78:09:64:dd:
d5:23:a8:ae:fd:a7:e3:15:68:a3:ca:3d:ae:59:39:
07:16:c5:ed:61:48:18:3a:3a:02:3c:0d:28:a6:14:
81:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
E3:F5:18:E5:25:CA:F8:2D:24:65:4A:25:19:6C:E1:4E:F4:C2:EF:28
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:tuvock.serverpit.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
1.3.6.1.4.1.11129.2.4.2:
......w.U.....6.J...W<S...8xp%../..........c.^.......H0F.!.......x.`(.......5.~.8_.b._F..5J.!......QGo.o.4.........yqQ1...G....v.)<Q.T.9e..P.X...o.Xz)r......EG.x...c.^.......G0E.!..........$[.k.N.\....e.r.N1(H.*.. ]../#./.A.......-.......Y.....e.
Signature Algorithm: sha256WithRSAEncryption
07:e1:a7:7d:a2:94:4c:b0:7e:bc:3a:5f:d9:59:01:e0:e0:ea:
73:b4:11:a3:2f:47:d2:18:56:c2:f5:de:fb:bb:61:19:06:e7:
2a:c5:d2:20:14:33:f9:7e:c8:bb:7a:5f:61:08:1c:26:f3:bd:
71:6f:11:08:f0:6d:60:b1:85:bc:b2:0c:ad:0a:91:38:08:d9:
3f:b6:75:d4:8b:2b:29:f9:4b:7f:f4:2a:d9:6e:42:57:db:72:
9a:dc:a4:a7:22:2c:66:ad:e3:5c:13:6e:be:1c:d0:6a:15:04:
28:07:e6:6d:35:16:cb:65:55:db:8a:10:5f:d7:c6:d5:45:ea:
39:81:d6:2f:e3:c3:0a:e1:82:98:38:d0:6f:14:11:b9:17:f1:
f6:5d:0f:6e:ee:7d:9f:e9:5e:d9:5b:0f:f7:a8:da:ed:6d:a8:
8f:84:cc:05:fb:85:f4:6f:33:12:e9:7e:7a:32:88:47:a0:59:
2a:01:e5:d9:02:50:a0:8e:41:1a:a5:6d:c9:25:78:d0:7f:9e:
d1:c5:60:d6:6d:12:f3:d9:12:0f:a6:75:be:d4:43:89:23:c3:
e5:8d:a4:af:1d:a0:6e:73:5d:db:5d:f2:03:80:76:45:56:e4:
8c:16:40:f9:31:61:87:3a:93:2f:af:6d:b8:b9:66:41:0c:3d:
f9:37:1e:a0
I temporarily deleted the certificates from the server and then verified that these files get recreated when the certs are imported into the certificate manager from the Letsencrypt PEM files…
Sorry, I meant post the actual files rather than the result of parsing them with openssl x509. The problem with openssl x509 in debugging chains with extra certificates is that it only parses the first certificate in any given file.
Hi Schoen. Thank you so much for your help. I tried, but I don’t think I can upload those filetypes here. It is restricted to jpg, jpeg, png, gif, go, js, txt, pcap, pcapng. How can I send them or analyze them for extra certificates?
Thanks for that, @mkubly. That does show more about the problem—the chain file has three certificates (your site certificate, the Let’s Encrypt X3 intermediate, and the IdenTrust DST root). The cert file has just your site certificate, so when the two of these are combined, they include what we see when visiting your site:
the site certificate [from the cert file]
the site certificate again [from the chain file]
the Let’s Encrypt X3 certificate [from the chain file]
the DST root [from the chain file]
To correct this, we would want the chain file to contain only the Let’s Encrypt X3 certificate.
Can you tell us more about how you’re importing certificates into your Server Keychain application, what data you’re entering into it, and what the user interface looks like during the import operation?
So I don’t know where the DST root is coming from here, but I do think your pkcs12 command is wrong because cert.pem and fullchain.pem are already partially redundant with each other (each one contains a copy of the end-entity certificate). You should probably use either -in [...]/fullchain.pem (without -certfile), or -certfile [...]/chain.pem (rather than fullchain.pem). That should get one fewer redundancy, at least.
I don’t want to ask you to post the p12 file here, because it apparently contains your private key.
Unfortunately, that question didn’t seem to get a thorough answer on the other forum, but it looks like people felt that it was a specific bug in particular versions of OpenSSL on macOS, which were creating the p12 files incorrectly. Therefore this might work better if you could use a different version of OpenSSL, or use a different tool to create the p12 file. (My advice in my previous message might still be right, though.)
