Open an ssl connection to site
openssl s_client -connect client-cert-missing.badssl.com:443
returns
.
.
.
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni
i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Intermediate Certificate Authority
---
.
.
.
Verify return code: 21 (unable to verify the first certificate)
Even though the intermediate certificate is missing, browsers can still show no problems with https://client-cert-missing.badssl.com:
but tools like curl, java…. will report that they’re unable to find valid certification path to requested target.
To fix, you have two options
-
find and add the intermediate certificate that https://client-cert-missing.badssl.com use to your keystore
# add to ubuntu keystore sudo cp COMODORSADomainValidationSecureServerCA.crt /usr/local/share/ca-certificates/COMODORSADomainValidationSecureServerCA.crt sudo update-ca-certificates # add to java keystore sudo keytool -importcert -alias COMODORSADomainValidationSecureServerCA -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file COMODORSADomainValidationSecureServerCA.crt
-
Or update your webserver to send the full chain of certificates not just the leaf chain
https://nginx.org/en/docs/http/configuring_https_servers.html
Some browsers may complain about a certificate signed by a well-known certificate authority, while other browsers may accept the certificate without issues. This occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority provides a bundle of chained certificates which should be concatenated to the signed server certificate. The server certificate must appear before the chained certificates in the combined file:
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
The resulting file should be used in the ssl_certificate directive:
server { listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.chained.crt; ssl_certificate_key www.example.com.key; ... }
I am having trouble with OpenSSL complaining about not being able to validate locally issued certificate where I have the CA chain as well. I have the locally issued cert in (PEM and CRT) in addition to the local CA chain certificate (CER,PEM,CRT). The root and issuer are the same server. Comparing text on both certs, both match on «issuer:» field on both. This is RedHat Linux server.
I am getting error «verify error:num=20:unable to get local issuer certificate» and «Verify return code: 21 (unable to verify the first certificate)».
I am not sure what to look for anymore.
Troubleshooting steps
-
I did add the Issuer CA cert to linux certs using
cerutil certutil -d /etc/pki/nssdb -A -t "C,," -n DomainA1-Server1CA -i /root/DomainA1-Server1CA.cer
-
Ran
certutil -d /etc/pki/nssdb -L
and I can see the cert there:Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
DomainA1-Server1CA C,, -
Ran
openssl s_client -connect ServerA2:443 -CAfile /root/certs/DomainA1-Server1CA.cer
, tried with (.CRT and .PEM), got the two errors above. -
Ran
openssl s_client -connect ServerA2:443 -CApath /root/certs
, tried with (.CRT and .PEM), got the two errors above. -
Ran
openssl s_client -connect ServerA2:443
, got the two errors above.
Issued Cert snippet
Data:
Version: 3 (0x2)
Serial Number:
54:a9:50:a3:00:01:00:00:14:47
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=com, DC=domainA1, CN=DomainA1-Server1CA
Validity
Not Before: April 5 16:45:48 2017 GMT
Not After : April 5 16:45:48 2019 GMT
Subject: C=US, ST=NY, L=CityA, O=CompanyNAME, OU=IT,
CN=ServerB1.DomainA1.com
CA Chain Cert
Data: Version: 3 (0x2)
Serial Number: 19:11:eb:af:4c:d5:a9:94:49:ka:2f:41:f2:e1:09:g2
Signature Algorithm: sha256WithRSAEncryption
Issuer: DC=com, DC=domainA1, CN=DomainA1-Server1CA
Validity
Not Before: Aug 15 18:41:45 2015 GMT
Not After : Aug 15 18:41:45 2025 GMT Subject: DC=com, DC=domainA1,
CN=DomainA1-Server1CA Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public-Key: (2048 bit)
...C.A
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
To check your installed SSL certificate for errors, run this OpenSSL command from the Hipchat Server console:
echo | openssl s_client -showcerts -connect $(hostname):443 -CApath /etc/ssl/ && echo | openssl s_client -connect $(hostname):443 2>/dev/null | openssl x509 -noout -dates -text
This command checks the SSL certificate and chain(s) installed on Hipchat Server, much like a client would request SSL information to start a secure communication.
It details the public certificate chain and any errors that may cause problems. You can run this command either on the server’s terminal / SSH console itself or externally:
- Internal: Use the command provided above
- Externally: Change the $(hostname) section to the hostname and domain of the server that you are running the check on. For example, hipchat.example.com
When using the comprehensive OpenSSL check, a correctly installed SSL certificate looks like this for example:
HipChat SSL Example
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = "Example Inc.", CN = *.example.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=CA/L=San Francisco/O=Example, Inc./CN=*.example.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=CA/L=San Francisco/O=Example, Inc./CN=*.example.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3277 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 9DB8577FB02B4CAD515ECE59E22194DC8F1D5BD7F19D6A016B15A445A2F2919F
Session-ID-ctx:
Master-Key: AAFA57013D6A42D45F6D36F36552887464832281FB409003DCCAE94A1235E46CCBA390827E10D41CBDA38A11C4C9BE42
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - b3 e6 08 37 ae f5 fa 66-e4 ac c6 a9 0d 97 d2 b8 ...7...f........
0010 - 22 63 24 40 7b ea 1d 1f-9c ea cd 02 a6 dc 2f 22 "c$@{........./"
0020 - 91 8c 9d 55 98 57 af 14-7b 61 60 93 d1 8c 44 14 ...U.W..{a`...D.
0030 - 6f e1 9a e2 14 b0 d7 af-76 ba ad 70 d3 78 66 96 o.......v..p.xf.
0040 - af 9d e2 c4 7d 8e 4f df-a1 88 48 38 7e 28 ca d2 ....}.O...H8~(..
0050 - aa 37 61 1b 69 cf a0 ea-5e e1 0e 63 2d 79 ce a2 .7a.i...^..c-y..
0060 - 9f d2 ea f6 8e bf b4 fe-60 15 9a aa 03 7e 4b 7d ........`....~K}
0070 - 87 55 92 27 60 b0 1d e9-fa ab fe 32 25 82 e8 be .U.'`......2%...
0080 - 6d 5a e4 db 60 c7 ae 9d-67 c3 96 b8 94 83 28 9c mZ..`...g.....(.
0090 - 8d a0 47 40 a0 88 12 ab-37 46 bf 70 4d 05 d1 0e ..G@....7F.pM...
00a0 - aa 76 e8 da ad 0c b1 61-56 c9 12 d2 0b 91 d7 11 .v.....aV.......
Start Time: 1510550546
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
notBefore=Aug 31 00:00:00 2016 GMT
notAfter=Sep 5 12:00:00 2018 GMT
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:d8:87:50:83:2d:b7:58:48:50:72:7b:81:92:24:3c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
Validity
Not Before: Aug 31 00:00:00 2016 GMT
Not After : Sep 5 12:00:00 2018 GMT
Subject: C=US, ST=CA, L=San Francisco, O=Example, Inc., CN=*.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a6:04:43:0f:6a:27:eb:19:40:14:65:b1:2f:91:
d7:64:14:90:f3:75:f1:8a:78:59:b6:90:31:6a:ea:
ce:3b:fa:f4:a8:d9:74:af:01:41:6f:68:c8:8a:59:
38:1e:39:5f:0b:73:7c:51:90:81:52:b4:d2:8e:8f:
1f:89:c7:81:14:86:9c:77:4b:98:75:a1:e8:bf:21:
b3:95:60:e9:56:d9:9a:62:94:d1:35:e0:e1:f8:d4:
4a:8d:5f:61:4e:01:3d:94:23:74:64:a0:f8:db:de:
6f:75:c3:2d:54:15:f1:c6:ba:aa:2d:9d:6b:40:d9:
18:64:3c:96:a4:77:27:c5:df:c4:17:59:b6:18:95:
28:72:1d:64:45:9a:5f:f1:13:10:69:79:3a:be:8d:
2b:bf:72:b0:08:5c:b6:13:a3:2d:e5:52:be:6d:7e:
20:95:40:92:6e:bd:32:f4:0a:ca:09:5c:e1:3d:4a:
2b:2b:38:14:2c:8a:c1:a4:44:fa:cd:0d:d3:9b:64:
2f:95:6d:67:ae:25:5b:64:4c:5e:3c:50:c7:d7:0b:
42:bd:d5:06:97:32:12:b6:f5:66:af:62:d9:cd:db:
46:9b:42:29:09:2b:d6:f5:12:be:86:97:73:73:da:
02:b1:08:53:59:a3:0e:4f:74:7b:52:1a:d6:76:ab:
7d:71
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B
X509v3 Subject Key Identifier:
03:E6:D2:4D:86:76:9B:5F:88:AD:C8:BE:39:BC:5B:8A:98:D9:85:55
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/sha2-ha-server-g5.crl
Full Name:
URI:http://crl4.digicert.com/sha2-ha-server-g5.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.1.1
CPS: https://www.digicert.com/CPS
Policy: 2.23.140.1.2.2
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha256WithRSAEncryption
24:11:15:ca:a4:89:e7:dc:1b:2b:be:6b:c3:b4:8e:6b:60:aa:
86:26:9d:3b:d0:44:43:21:bc:2e:71:ad:08:c0:aa:b8:30:fd:
aa:99:0d:4e:34:d5:14:d4:f6:ca:6d:fe:f9:69:48:3b:df:da:
66:22:74:a5:16:3f:53:e7:00:23:d1:17:ad:7b:ad:30:e8:ae:
04:ef:99:3d:03:40:cd:ac:14:04:22:ee:11:86:14:f7:57:23:
e2:14:07:83:37:23:42:07:04:2e:8d:dc:3e:fa:0d:83:f8:4c:
47:8f:f6:d4:fc:9c:28:cb:00:7c:fa:91:f2:88:64:6a:c2:73:
0f:96:69:e5:5c:7e:58:3f:6a:25:35:56:36:66:d5:92:5f:9f:
86:c9:04:7a:ef:05:64:c1:60:c5:a8:a5:13:bd:fa:a6:af:73:
41:e2:13:38:cf:d5:f6:8f:a7:9d:26:2a:83:23:f4:b3:6f:08:
d3:25:72:3a:3e:5a:76:c5:b7:2b:46:f8:28:1e:05:25:8d:8e:
6c:a0:ff:9a:e0:38:cb:e4:93:2a:d9:2a:62:70:f2:b0:72:ff:
0e:8d:da:14:2b:d0:93:98:a2:ee:b9:d6:d8:36:63:1d:2b:47:
bd:3b:bb:6c:62:25:35:ce:c2:a1:29:97:f7:5b:9a:ad:d4:96:
4d:3d:36:93
In this example, there are two certificates listed in the certificate chain. Usually, certificate 0
is the primary certificate and can be easily identified by the CN
which should list the fully qualified domain name (FQDN). Certificate 1
is the intermediate certificate.
Root Cert
If a certificate is installed that has the same subject and issuer line (also called a self-signed certificate), then, more than likely, that is a root certificate and needs to be removed from the chain (because the root certificates are normally housed in the client trust-store).
Common OpenSSL Error Codes
Error Code | Description |
---|---|
verify error:num=27:certificate not trusted | This normally comes together with the errors num=21 where the server doesn’t have the intermediate certificates needed to verify the SSL certificate. |
verify error:num=26:unsupported certificate purpose | This means that the certificate being installed isn’t a Server certificate and cannot be used for Server SSL handshaking. |
verify error:num=21:unable to verify the first certificate | This can mean that either some or all the intermediate certificates required to establish the chain of trust between the primary certificate (the one you buy from a CA vendor) and the Root certificate (housed and served by the client) is missing. See below for troubleshooting steps. |
verify error:num=20:unable to get local issuer certificate |
The -CApath is not specified or not found. Verify that the -CApath is pointed to the local certificate store. For Hipchat Server that is /etc/ssl/ but may be different depending on what console/terminal you are using to query the Server. See below for troubleshooting steps. |
Verify return code=19:self signed certificate in certificate chain | One or more of the certificates in the chain has a self-signed certificate. Root CA certificates are almost always self-signed. See below for troubleshooting steps. |
Verify return code=18:self signed certificate | The default self signed certificate that comes together during the installation of Hipchat Server / generated through hipchat certificates —selfsign command is still being used in the instance. See below for troubleshooting steps. |
Error — Unsupported Certificate Purpose
When running an OpenSSL check against a CSR or a CRT file, you may see this error:
verify error:num=26:unsupported certificate purpose
Troubleshooting
-
Run the following command inside Hipchat Server command line interface:
Check against installed SSL certificate
openssl s_client -showcerts -connect localhost:443 </dev/null 2>/dev/null|openssl x509 -text |grep v "$(grep -E -A1 "Key Usage")"
or run a check against your .crt file:
Check against a .crt file
openssl x509 -text -noout -in <filename for crt>.crt
- In the output under X509v3 Extended Key Usage should be the following line: TLS Web Server Authentication
- If this line is missing, then the certificate isn’t specifically setup for Server handshaking. You will need to reach out to your CA and ask them to generate a Server certificate.
- If the command returns grep: : No such file or directory then you do not have the certificate installed (are you using a self-signed certificate?)
Cause
This error specifically states that the intended purpose of the certificate installed does not include the role to act as a Server certificate thus cannot be used for handshaking when a client attempts to connect.
Error — Unable to verify the first certificate
When running OpenSSL check, an installed SSL cert from trusted CA vendor shows the following error:
verify error:num=21:unable to verify the first certificate
Troubleshooting
- Verify that you have an intermediate certificate installed.
- If you have an intermediate certificate installed, it’s possible that you may need more than one to establish trust. This is common with vendors such as Entrust. Check with your vendor regarding how many intermediate certificates you need.
- You can use the GeoCerts SSL Checker tool to visually see your chain and check if any intermediate certs are missing.
- If you’ve recently installed a chain with an intermediate certificate, first snapshot or back up your instance. (This will disconnect any user that’s currently connected to the service.) Then restart the services (
HipChat service -restart
) or rebooting the Server (sudo reboot
).
Cause
The primary certificate (the one you purchase from a vendor) cannot establish the chain of trust between itself and the Root certificate stored locally. Usually installing the intermediate certificates fixes this.
Error — Unable to get local issuer certificate
When running OpenSSL check, an installed SSL cert from trusted CA vendor shows:
verify error:num=20:unable to get local issuer certificate
Troubleshooting
- Verify that you are using the
-CApath
argument when running the OpenSSL check. - Verify that the path to the local certificate storage is correct (Hipchat Server local certificate trust-store is
/etc/ssl
).
Cause
This error code is thrown when a local certificate path is not found during the OpenSSL check is used. This error is specific to the OpenSSL check. Generally, it can be ignored and doesn’t affect the trust of a certificate chain.
Error — Self-signed certificate in certificate chain
When running OpenSSL check, an installed SSL cert from trusted CA vendor shows:
Verify return code=19:self signed certificate in certificate chain
Troubleshooting
- Install a trusted CA signed primary SSL certificate and an intermediate certificate.
- Verify that the Root CA is not included in the certificate chain (as this is almost always self-signed).
- If you’ve removed the Root CA cert, first snapshot or back up your instance. (This will disconnect any user that’s currently connected to the service.) Then restart the services (
HipChat service -restart
) or rebooting the Server (sudo reboot
).
Cause
This error is thrown whenever there is a self-signed certificate in the chain. When Hipchat Server is booted for the first time, it generates a self-signed certificate for testing purposes. We highly recommend replacing this certificate with a certificate chain from a trusted vendor.
Error — The certificate and key do not match
When uploading your SSL private key and certificate through the Hipchat Server administrative interface or command-line interface, the following error occurs:
Unable to update: The certificate and key do not match
Troubleshooting
Use the following commands to generate an MD5 sum for the private key, certificate signing request (CSR), and certificate files:
openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req -noout -modulus -in domain.csr | openssl md5
Verify that the output string from each command is identical to verify that the files are matching. If the outputs are identical but problem persists, try to re-install the SSL certificate you get from CA as cleanly as possible. Start with reconfiguring the server to use self-signed certificate and then re-import the trusted SSL certificate into the server again:
hipchat certificates --selfsign
cat hipchat-example-com.crt > new.pem
cat hipchat-example-com.key >> new.pem
hipchat certificates --import new.pem
If problem persists even after cleanly importing the certificate, there could be a problem with the certificate that the CA generated. Reach out to the CA to re-issue the SSL certificate followed by a re-installation of the new certificate on the server. On a side note, the wrong order of your SSL certificate could also produced similar error. Double check the SSL certificate format following the recommended format here: Creating or Obtaining an SSL Key and Certificate
Cause
The private key and certificate being uploaded do not match and are incompatible with each other. It will be necessary to re-form the private key, CSR, and/or certificate in such a way that they do match, at which point they can be uploaded to the Hipchat Server.
Error — self signed certificate
Consider purchasing a trusted CA signed SSL certificate to tackle this issue permanently.
SSL Certificate Chain Ideal Setup
As listed in the Creating or Obtaining an SSL Key and Certificate, when installing the SSL certificate chain in Hipchat Server, please make sure that your .pem
file includes the RSA private key, the primary certificate and an intermediate certificate. This gives the certificate chain the best chance of minimizing problems with trust in Hipchat Server.
ECC Certificates
At this time, Hipchat Server is not compatible with ECC (Elliptic Curve Cryptography) or ECDH (Elliptic Curve Diffie–Hellman) generated SSL certificates.
Trust Issues
The chain of trust extends from the root certificate (also called the anchor certificate) to the intermediate certificate then to the primary certificate. If there are any errors or issues with trust throughout the chain, the following issues may happen:
- Unable to install integrations
- SSL warnings in the Hipchat client when it connects
- Mobile apps may not connect with the Require Certificate Authentication option checked
- Push notifications will not work
- Emoticons may not render
- Desktop client failed to reconnect
Self-Signed Certificates
Hipchat Server generates a self-signed certificate and private key when it is first deployed. This certificate is meant for testing purposes and is not recommended that you use it in a production environment.
To ensure that the functionalities of Hipchat Server are not affected in any way, we always recommend you to obtain a trusted CA signed full certificate chain applied on your instance.
Internally Signed SSL Certificates
If your group is using an SSL certificate signed by an internal CA (opposed to a vendor like DigiCert), the internal CA will need to provide the corresponding RSA private key, primary, and intermediate certs to install in Hipchat Server. Once the SSL chain is installed in Hipchat Server, install the root certificate into the trust-store of the OS running the Hipchat client. This adds the certificate as ‘trusted’ which is needed when connecting to the Hipchat Server certificate chain. If the root certificate is not installed in the OS running the Hipchat client, then the trust will not be established and you may have problems connecting the client.
Links
- Why you don’t want EV certificate
- SSL confg generator
- openssl homepage
- http://gagravarr.org/writing/openssl-certs/index.shtml
Tools
- openssl
- sslscan
- sclient
- gnutls-cli
Documentation and HOWTOs
- OpenSSL Certificate Authority Setup
- Validating a Certificate Path with OpenSSL
- How SSL and TLS work
- OpenSSL Certificate Authority
- http://dataslinger.com/index.php?/archives/5-Configuring-SSL-certificates-for-Apache,-Dovecot,-Sendmail,-and-IIS.html
- ssl cert HOWTO
- OpenSSL Command-Line HOWTO
- 1. Way: SubjectAltName Only
- OpenSSL Command-Line HOWTO
- How to Create a .PEM file for SSL Certificate Installation
- http://www.tc.umn.edu/~brams006/selfsign.html
- Verifying that a Private Key Matches a Certificate
- Getting your certificate chain right
- Verify certificate chain
- Checking A Remote Certificate Chain With OpenSSL
- Check SSL Certificate Chain with OpenSSL Examples
Dovecot and ssl
Networksolutions certs: After creating myserver.key and myserver.csr and obtaining certs: (don’t forget to insert newlines between the blocks!)
cat OV_NetworkSolutionsOVServerCA2.crt OV_USERTrustRSACertificationAuthority.crt AddTrustExternalCARoot.crt > intermediate.pem
In dovecot.conf:
ssl_cert_file = /usr/local/etc/IMAP.EXAMPLE.COM.crt ssl_key_file = /usr/local/etc/myserver.key #optional, only if you want to require client to provide cert #ssl_ca_file = /usr/local/etc/intermediate.pem
Courier-imap and ssl
- http://linsec.ca/Using_Courier-IMAP_and_SSL
- http://linux.seindal.dk/2005/12/04/making-a-courier-imap-ssl-sertificate/
Networksolutions certs: After creating myserver.key and myserver.csr and obtaining certs: (don’t forget to insert newlines between the blocks!)
cat AddTrustExternalCARoot.crt NetworkSolutions_CA.crt > intermediate.pem cat myserver.key >> IMAP.EXAMPLE.COM.crt
In imapd-ssl:
TLS_CERTFILE=/usr/local/etc/courier-certs/IMAP.EXAMPLE.COM.crt TLS_TRUSTCERTS=/usr/local/etc/courier-certs/intermediate.pem
Network Solutions certificates bundle
See http://blog.irontechsolutions.com/2008/12/10/ssl-chained-certificates-explained/
cat OV_NetworkSolutionsOVServerCA2.crt OV_USERTrustRSACertificationAuthority.crt AddTrustExternalCARoot.crt > intermediate.txt
Comodo bundle order
COMODORSAOrganizationValidationSecureServerCA. + COMODO rsa add trust ca ( + addtrustexternalcaroot )
Generate a signing request
openssl req -nodes -newkey rsa:2048 -keyout my.domain.key -out my.domain.csr
The resulting csr is the signing request, my.domain.key is the private key you save not readable for anyone but root!
Tips&Tricks
Create private key (using config file)
openssl req (-config /etc/pki/tls/www.example.com.cnf) -newkey rsa:2048 -nodes -keyout domain.key
Create CSR using config file
openssl req -config /etc/pki/tls/www.example.com.cnf -new -newkey rsa:2048 -nodes -keyout example.com.key -out www.example.com.csr
Convert der to pem
openssl x509 -inform der -in certificate.cer -out certificate.pem
Creating CSR for multiple hosts
For example http://blog.endpoint.com/2014/10/openssl-csr-with-alternative-names-one.html
Remove password from private key
https://wiki.apache.org/httpd/RemoveSSLCertPassPhrase
Examining certificates
- http://www.madboa.com/geek/openssl/#verify-standard
openssl verify cert.pem
openssl x509 -in cacert.pem -noout -text openssl x509 -in foo.pem -inform pem -noout -text
openssl rsa -noout -text -in server.key openssl req -noout -text -in server.csr openssl rsa -noout -text -in ca.key openssl x509 -noout -text -in ca.crt
with expiration date:
openssl x509 -noout -text -enddate -in ca.crt
- to check CN
openssl x509 -in server.crt -noout -subject
openssl pkcs12 -info -in keyStore.p12 openssl pkcs12 -info -in keyStore.pfx
Checking a service
- Note -CApath should point to your local collection of public CA certs
openssl s_client -connect -CApath /etc/ssl/certs host:pop3 -starttls pop3 openssl s_client -port 443 -CApath /etc/ssl/certs -host webmail.example.com -prexit openssl s_client -connect imap.example.com:143 -starttls imap openssl s_client -connect web.server:443 -showcerts openssl s_client -connect webmail.example.com:443 -servername vhost.example.com
Just check expiration date:
openssl s_client -connect imap.example.com:143 -starttls imap 2>/dev/null | openssl x509 -noout -dates
Check your site
- https://www.ssllabs.com/ssltest
- https://www.sslcheck.nl/
gnutls-cli
echo quit | gnutls-cli --starttls-proto smtp --port 25 servac.skk | grep Status echo quit | gnutls-cli --port 465 servac.skk | grep Status
check if certs match
TODO: -clr_check too
openssl pkey -in privateKey.key -pubout -outform pem | sha256sum openssl x509 -in certificate.crt -pubkey -noout -outform pem | sha256sum openssl req -in CSR.csr -pubkey -noout -outform pem | sha256sum
These values show match Also:
openssl verify -CAfile ca-bundle foo_bar.crt
A script to do these checks: [sslcheck]
Creating your own CA and signing with it
(based on http://www.eclectica.ca/howto/ssl-cert-howto.php#rootc)
cd /etc/ssl mkdir newcerts (perform secret rituals)
FAQ
Error messages
OpenSSL: error:0A000102:SSL routines::unsupported protocol
This could becaure you’re trying to an older version of TLS, check openssl.cnf for
CipherString = DEFAULT:@SECLEVEL=2
which means it enforces minimum of TLSv1.2
You might now get
OpenSSL: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
which means add below the CipherString line:
Options = UnsafeLegacyRenegotiation
Get issuer
openssl s_client -showcerts -connect <YOURHOST>:443 < /dev/null 2>/dev/null |grep -i issuer
Order of certificates in bundle
Root CA comes last
using s_client
no client certificate sent
try adding -cert
Secure Renegotiation IS NOT supported
Probably using wrong TLS version
Can’t use SSL_get_servername
Try using hostname instead of IP address
write:errno=104
server reset the connection
no peer certificate available
Could be trying to talk tls to ssl?
unable to load client certificate private key file
Verification error: unable to verify the first certificate
problem missing CA cert
error 20 at 0 depth lookup: unable to get local issuer certificate
you probably need to provide the right -CAfile maybe self signed?
Verify return code: 21 (unable to verify the first certificate)
Probably requires bundle
Bad certificate (code 42)
Means the server demands you authenticate with a certificate, and you did not do so, and that caused the handshake failure.
check certificate chain
openssl s_client -connect www.example.com:443 -showcerts
Some of the output
Certificate chain
0 s:CN = foo.local i:CN = foo.local-CA
0: first in chain
s: subject ( openssl x509 -noout -in foo.crt -subject )
i: issuer ( openssl x509 -noout -in foo.crt -issuer )
OR
openssl s_client -showcerts -verify 5 -connect ldap.example.com:636 < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/) {a++}; out="bluePage-cert"a".pem"; print >out}'
or
openssl s_client -showcerts -verify 5 -connect ldap.example.com:389 starttls ldap < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/) {a++}; out="bluePage-cert"a".pem"; print >out}'
check expiration date
echo | openssl s_client -servername NAME -connect HOST:PORT 2>/dev/null | openssl x509 -noout -dates
openssl x509 -enddate -noout -in file.pem
139814102202256:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
i’ve seen this happen when someone deleted the BEGIN/END CERTIFICATE lines
or a file is in DER format
SSL CTX certificate file error: error:0906D06C:PEM routines:PEM_read_bio:no start line
??
check if webserver supports old tls
openssl s_client -connect www.example.com:443 -tls1 openssl s_client -connect www.example.com:443 -tls1_1
or when vhost:
openssl s_client -servername vhost.example.com -connect www.example.com:443 -tls1_1
ERROR: Certificate verification: Not trusted
seems to be an lftp issue
unsupported certificate purpose
??
ssllabs checks
Chain issues: Incorrect order, Contains anchor
Could be the topmost cert in the bundle provided, try removing it
Chain issues: Contains anchor
Seems to mean there’s a root ca in the bundle
check smtp submission
echo -n "username" | base64 echo -n "password" | base64
openssl s_client -connect mail.host.com:587 -starttls smtp -crlf
EHLO foo.bar AUTH LOGIN
base64username
base64password
OR
echo -ne 'usernamepassword'| base64 AUTH LOGING output_of_that_echo
Peer’s Certificate issuer is not recognized.
p12 / pkcs12
https://fileinfo.com/extension/p12
openssl pkcs12 -in yourP12File.pfx -nocerts -out privateKey.pem openssl pkcs12 -in yourP12File.pfx -clcerts -nokeys -out publicCert.pem
server certificate does NOT include an ID which matches the server name
todo