Verification error unable to verify the first certificate openssl

How to fix SSL unable to verify the first certificate - Fix_SSL_unable_to_verify_the_first_certificate.md

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

  1. 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
  2. In the output under X509v3 Extended Key Usage should be the following line: TLS Web Server Authentication
  3. 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.
  4. 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

  1. Verify that you have an intermediate certificate installed.
  2. 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.
  3. You can use the GeoCerts SSL Checker tool to visually see your chain and check if any intermediate certs are missing.
  4. 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

  1. Verify that you are using the -CApath argument when running the OpenSSL check.
  2. 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

  1. Install a trusted CA signed primary SSL certificate and an intermediate certificate.
  2. Verify that the Root CA is not included in the certificate chain (as this is almost always self-signed).
  3. 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
  1. 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

  1. 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

Понравилась статья? Поделить с друзьями:
  • Veracrypt ошибка 8299
  • Veeam error access is denied
  • Vd error verr path not found opening image
  • Vba ошибка поддержки безопасных каналов
  • Vba runtime error 5991