(This answer extracted from X509_verify_cert at crypto/x509/x509_vfy.c:204, in openssl-1.0.2m)
The OpenSSL verify application verifies a certificate in the following way: It builds the certificate chain starting with the target certificate, and tracing the issuer chain, searching any untrusted certificates supplied along with the target cert first. Upon failing to find an untrusted issuer cert, OpenSSL switches to the trusted certificate store and continues building the chain. This process stops when
- an issuer is not found in the trusted store.
- a self-signed certificate is encountered.
- the max-verify depth is encountered.
At this point we have a chain that may end prematurely (if we failed to find an issuer, or if we exceeded the verify depth).
OpenSSL then scans over each trusted certificate on the chain looking for SSLv3 extensions that specify the purpose of the trusted certificate. If the trusted certificate has the right «trust» attributes for the «purpose» of the verification operation (or has the anyExtendedKeyUsage attribute) the chain is trusted. (Forgive the hand-wave on trust attributes, that part of the code was difficult to read.)
So lets test it out. First, let’s repro the OP’s error cases:
#
echo "Making Root CA..."
openssl req -newkey rsa:4096 -nodes -keyout ca-key.pem -sha384 -x509 -days 365 -out ca-crt.pem -subj /C=XX/ST=YY/O=RootCA
echo "Making Intermediate CA..."
openssl req -newkey rsa:3072 -nodes -keyout int-key.pem -new -sha384 -out int-csr.pem -subj /C=XX/ST=YY/O=IntermediateCA
openssl x509 -req -days 360 -in int-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out int-crt.pem
echo "Making User Cert..."
openssl req -newkey rsa:2048 -nodes -keyout usr-key.pem -new -sha256 -out usr-csr.pem -subj /C=XX/ST=YY/O=LockCmpXchg8b
openssl x509 -req -days 360 -in usr-csr.pem -CA int-crt.pem -CAkey int-key.pem -CAcreateserial -out usr-crt.pem
echo ""
echo "Making Chain..."
cat ca-crt.pem int-crt.pem > chain.pem
echo ""
echo "Verfying UserCert via RootCA..."
openssl verify -CAfile ca-crt.pem usr-crt.pem
echo ""
echo "Verfying UserCert via IntermediateCA..."
openssl verify -CAfile int-crt.pem usr-crt.pem
echo ""
echo "Verfying UserCert via chain..."
openssl verify -CAfile chain.pem usr-crt.pem
yields
[... Skipping OpenSSL KeyGen / CertGen verbosity ...]
Making Chain...
Verfying UserCert via RootCA...
usr-crt.pem: C = XX, ST = YY, O = LockCmpXchg8b
error 20 at 0 depth lookup:unable to get local issuer certificate
Verfying UserCert via IntermediateCA...
usr-crt.pem: C = XX, ST = YY, O = IntermediateCA
error 2 at 1 depth lookup:unable to get issuer certificate
Verfying UserCert via chain...
usr-crt.pem: OK
Now, lets use the -addtrust option of openssl x509 to make sure we have one of the acceptable trust attributes on the intermediate CA (call this one IntermediateCAWithTrust; we’ll use it to sign AnotherUserCert.):
echo ""
echo "Alternate Intermedate CA (using -addtrust anyExtendedKeyUsage)"
echo ""
echo "Making IntermediateCAWithTrust..."
openssl req -newkey rsa:3072 -nodes -keyout int-key2.pem -new -sha384 -out int-csr2.pem -subj /C=XX/ST=YY/O=IntermediateCAWithTrust
openssl x509 -req -days 360 -in int-csr2.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out int-crt2.pem -addtrust anyExtendedKeyUsage
echo "Making AnotherUser Cert..."
openssl req -newkey rsa:2048 -nodes -keyout usr-key2.pem -new -sha256 -out usr-csr2.pem -subj /C=XX/ST=YY/O=LockCmpXchg8b_2
openssl x509 -req -days 360 -in usr-csr2.pem -CA int-crt2.pem -CAkey int-key2.pem -CAcreateserial -out usr-crt2.pem
echo ""
echo "Verfying AnotherUserCert via IntermediateCAWithTrust..."
openssl verify -CAfile int-crt2.pem usr-crt2.pem
This yields
Alternate Intermedate CA (using -addtrust anyExtendedKeyUsage)
Making IntermediateCAWithTrust...
[... Snip more OpenSSL generation output ...]
Making AnotherUser Cert...
[... Snip more OpenSSL generation output ...]
Verfying AnotherUserCert via IntermediateCAWithTrust...
usr-crt2.pem: OK
Hey look! we just successfully verified AnotherUserCert via the IntermediateCAWithTrust, even though we didn’t supply the whole chain. The key to this difference is that any one of the trusted certificates in the chain had an appropriate trust attribute for the verify operation.
Looking a little closer (via openssl x509 -in ca-crt.pem -noout -text), our CA certificate has
X509v3 Basic Constraints:
CA:TRUE
which I would imagine OpenSSL treats as a general «may verify for any purpose» extension. The new IntermediateCAWithTrust does not have X509v3 Basic Constraints, but instead has
Trusted Uses:
Any Extended Key Usage
No Rejected Uses.
For more info in the -addtrust option, and the types of trust attributes that can be added, see https://www.openssl.org/docs/manmaster/man1/x509.html#TRUST_SETTINGS
Near the bottom of that page is a concise summary of the preceding discussion:
The basicConstraints extension CA flag is used to determine whether
the certificate can be used as a CA. If the CA flag is true then it is
a CA, if the CA flag is false then it is not a CA. All CAs should have
the CA flag set to true.If the basicConstraints extension is absent then the certificate is
considered to be a «possible CA» other extensions are checked
according to the intended use of the certificate. A warning is given
in this case because the certificate should really not be regarded as
a CA: however it is allowed to be a CA to work around some broken
software.
So, in short, make sure your intermediate CAs are properly CAs (in their X509v3 Basic Constraints). This seems an excellent tutorial (and it explicitly generates the intermediate CA as a CA): https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
As a backup plan, you can always supply the whole chain, or you can make your intermediate CAs with the -addtrust hack.
“Unable to get Local Issuer Certificate” is a common SSL certificate error. It is related to the incomplete certificate chain such as (most commonly) missing the intermediate certificate. The fix is to ensure the entire certificate chain is present.
We will dive into this issue to see why this happens and how to fix it.
Understanding certificate chain
A certificate chain is an ordered list of certificates, containing an SSL/TLS server certificate, intermediate certificate, and Certificate Authority (CA) Certificates, that enable the receiver to verify that the sender and all CA’s are trustworthy.
- Root Certificate. A root certificate is a digital certificate that belongs to the issuing Certificate Authority. It comes pre-downloaded in most browsers and is stored in what is called a “trust store.” The root certificates are closely guarded by CAs.
- Intermediate Certificate. Intermediate certificates branch off root certificates like branches of trees. They act as middle-men between the protected root certificates and the server certificates issued out to the public. There will always be at least one intermediate certificate in a chain, but there can be more than one.
- Server Certificate. The server certificate is the one issued to the specific domain the user is needing coverage for.
We will use these files in this example.
- CA certificate file (usually called ca.pem or cacerts.pem)
- Intermediate certificate file (if exists, can be more than one. If you don’t know if you need an intermediate certificate, run through the steps and find out)
- Server certificate file
How to get a free SSL certificate?
If you need a free SSL certificate for your website, Elementor Cloud Website is a great option. They offer fast speeds, good uptime, and excellent customer support. It is an end-to-end solution gives you everything you need in one place for your website. Web Hosting on Google Cloud + SSL certificate + WordPress + Website Builder + Templates.
We recommend using Elementor Cloud Website to build a website. It is very easy to start. You can get your website online in minutes. The price is $99 for one year. Plus, they offer a 30-day money-back guarantee, so you can try it out with no risk.
How do Certificate Chains work?
When we install our TLS certificate, we also be sent an intermediate root certificate or bundle.
When a browser downloads our website’s TLS certificate upon arriving at our homepage, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate.
If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate.
View Certificate Chain
Use the openssl utility that can display a certificate chain. The following command will display the certificate chain for google.com.
openssl s_client -connect google.com:443 -servername google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
In the openssl output, the numbered lines start with the server certificate (#0) followed by the intermediate (#1) and the root (#2).
The s: indicates the certificate subject, and i: indicates the issuing certificate’s subject.
Guidelines to verify the certificate chain is valid
- Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
- Subject and Issuer are the same for the root certificate.
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.
- The Subject of the intermediate certificate matches the Issuer of the entity certificate.
- The Subject of the root certificate matches the Issuer of the intermediate certificate.
- The Subject and Issuer are the same in the root certificate.
Example of a valid certificate chain
server certificate
openssl x509 -text -in entity.pem | grep -E '(Subject|Issuer):'
Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
Subject: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.enterprise.apigee.com
Intermediate certificate
openssl x509 -text -in intermediate.pem | grep -E '(Subject|Issuer):'
Issuer: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Subject: C = US, O = Google Trust Services, CN = GTS CA 1O1
Root certificate
openssl x509 -text -in root.pem | grep -E '(Subject|Issuer):'
Issuer: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Subject: OU = GlobalSign Root CA – R2, O = GlobalSign, CN = GlobalSign
Check SSL Certificate with OpenSSL
Validate certificate chain with server and root Certificate
openssl verify cert.pem
cert.pem: C = Country, ST = State, O = Organization, CN = FQDN
error 20 at 0 depth lookup:unable to get local issuer certificate
We can use the following two commands to make sure that the issuer in the server certificate matches the subject in the ca certificate.
openssl x509 -noout -issuer -in cert.pem
issuer= /CN=the name of the CA
$ openssl x509 -noout -subject -in ca.pem
subject= /CN=the name of the CA
In the following case, we need to add the CAfile to verify the root certificate.
$ openssl verify -CAfile ca.pem cert.pem
cert.pem: OK
Validate certificate chain with server, intermediate, and root Certificate
$ openssl verify cert.pem
cert.pem: C = Countrycode, ST = State, O = Organization, CN = yourdomain.com
error 20 at 0 depth lookup:unable to get local issuer certificate
To complete the validation of the chain, we need to provide the CA certificate file and the intermediate certificate file when validating the server certificate file.
We can do that using the parameters CAfile (to provide the CA certificate) and untrusted (to provide intermediate certificate):
$ openssl verify -CAfile ca.pem -untrusted intermediate.cert.pem cert.pem
cert.pem: OK
If we have multiple intermediate CA certficates, we can use the untrusted parameter multiple times like -untrusted intermediate1.pem -untrusted intermediate2.pem .
Fix routines:X509_check_private_key:key values mismatch in 2 Ways
Related:
- Exploring SSL Certificate Chain with Examples
- Understanding X509 Certificate with Openssl Command
- OpenSSL Command to Generate View Check Certificate
- Converting CER CRT DER PEM PFX Certificate with Openssl
- SSL vs TLS and how to check TLS version in Linux
- Understanding SSH Key RSA DSA ECDSA ED25519
- Understanding server certificates with Examples
I’ve attempted to setup a certificate authority, and issue a certificate from that authority (with no intermediate inbetween The authority covers *.node.consul, and the certificate is underneath that at: i-0c2e25880dab06f71.node.consul). However when executing openssl verify (passing in the -CAfile option), it seems to still not be able to complete the lookup:
root@i-0c2e25880dab06f71:~# openssl verify -verbose -CAfile /root/ssl-ca.crt /root/ssl-cert.pem
/root/ssl-cert.pem: CN = i-0c2e25880dab06f71.node.consul, emailAddress = ecoan@instructure.com, O = Instructure, OU = Ops, C = US, ST = UT, L = SLC
error 20 at 0 depth lookup:unable to get local issuer certificate
Reading in the certificates with:
openssl x509 -in /root/ssl-cert.pem -text -noout
Leads to the following two outputs:
for the ca:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d3:f3:bc:d7:8f:6c:43:2f:ad:9b:6c:3e:1d:13:8e:c4
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=*.node.consul/emailAddress=ecoan@instructure.com, O=Instructure, OU=Ops, C=US, ST=UT, L=SLC
Validity
Not Before: Jan 1 16:52:31 2018 GMT
Not After : Jan 1 16:52:31 2038 GMT
Subject: CN=*.node.consul/emailAddress=ecoan@instructure.com, O=Instructure, OU=Ops, C=US, ST=UT, L=SLC
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:be:15:5d:e3:32:b0:58:bf:01:7b:73:c2:ad:b6:
7c:59:9f:ca:a0:6a:26:64:8b:56:83:6e:43:b6:aa:
e9:81:70:39:70:22:bd:10:a4:d8:d1:a1:a1:cb:0d:
eb:d2:5c:c3:f8:9c:d2:d9:a5:d0:48:65:bb:d1:a8:
1a:cc:a4:53:27:9a:ca:fc:23:84:e3:f7:59:97:d6:
05:35:f5:94:5e:af:aa:a8:4f:24:25:0a:8e:e1:21:
6a:35:a5:e7:da:ed:f4:50:2c:cc:ef:ac:a6:28:da:
c1:a3:ea:53:84:64:9f:2c:a0:6a:73:6a:8d:e6:7e:
03:10:dd:42:cc:89:24:13:d7:5d:14:43:e2:cc:9a:
12:ef:4b:c6:96:fb:20:88:0e:fc:6c:b3:88:ba:ed:
64:d9:f7:8f:97:e1:50:a0:ae:42:5f:4f:8e:8f:7e:
40:fd:e5:a3:f4:1d:fc:88:f0:c3:2e:d1:1d:32:fb:
95:85:00:23:ba:d3:cc:0c:65:8e:be:e0:dd:4f:5f:
22:fe:26:8d:1c:12:94:0a:d1:44:4d:0c:be:72:56:
c6:7e:be:cb:81:41:0f:20:d8:31:34:d9:4c:11:ae:
c5:12:57:35:bf:15:8c:ea:15:88:29:2d:81:c8:11:
fb:a8:13:7a:cb:eb:68:f8:32:47:98:fa:dc:86:a9:
07:4a:cf:96:0d:fd:ce:09:48:df:ac:f7:f4:57:d0:
13:d5:75:cc:3d:63:3c:26:2d:95:88:b7:f9:27:83:
2a:ff:1f:63:fd:b5:f0:e9:d3:cf:85:3b:7a:6e:0e:
56:46:70:29:1e:be:3f:02:81:81:0c:0b:d4:88:da:
7f:93:46:03:d1:0c:73:97:44:33:a3:0b:1a:a0:a6:
b5:4d:f1:95:ea:37:7f:ac:e2:71:e1:90:94:97:99:
5f:d8:84:f5:29:9e:9a:86:ff:cd:6e:7d:b0:64:2e:
a1:21:a8:4a:84:e3:6c:a9:ac:cf:62:3e:8f:fd:71:
14:c9:c1:dc:99:13:84:9a:47:9a:42:53:52:e0:72:
32:48:9d:1b:ab:ea:c4:97:24:20:a3:86:e3:d5:d5:
79:c6:bf:e1:b0:31:a7:8f:8d:bc:0b:f3:b4:ab:03:
f1:e2:68:08:e0:3a:c3:50:3e:c1:40:8b:42:ae:71:
7d:7b:24:24:34:75:df:9f:b2:75:16:63:af:7b:58:
fb:eb:0c:8e:44:a7:1b:bb:59:c9:b4:db:c1:b4:9a:
c1:b1:42:a5:4b:62:b4:84:ab:c9:b0:6e:fe:db:20:
9e:32:24:0c:3c:dd:8b:82:9a:f6:75:76:73:6f:73:
f6:34:d8:02:b7:01:7c:e2:f7:90:43:5e:d0:00:dc:
0f:4d:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1
X509v3 Subject Alternative Name: critical
DNS:*.node.consul
Signature Algorithm: sha256WithRSAEncryption
53:52:50:d2:25:01:8f:7a:fb:03:18:2f:3c:cd:d2:85:4f:d2:
4d:39:8e:e4:06:bb:fa:8d:9a:9a:ab:e0:8f:ce:bb:6f:74:49:
1d:72:fb:27:e8:0f:bb:62:40:d7:06:69:71:4f:21:39:ac:ba:
78:b5:a8:43:8c:2d:6c:87:45:8e:75:9e:a4:79:65:cb:b0:bf:
47:0c:86:7a:a8:9b:40:80:71:30:a5:fe:db:1f:f2:2e:41:85:
f2:1d:8a:31:bd:ec:6d:94:58:a5:b5:93:25:6f:b8:bd:4e:13:
7a:40:d2:e2:bc:41:e6:33:fe:22:55:bb:01:5d:7e:af:8d:62:
9b:9f:9d:c9:e8:63:4d:7a:b5:f9:13:8f:f3:45:68:a8:1f:e7:
d5:5b:cc:77:49:eb:c9:26:3d:19:50:b6:34:e8:e4:21:14:37:
aa:76:d0:e0:77:69:77:ab:6a:da:0d:e7:22:6d:23:61:5c:8b:
da:64:da:48:5a:6f:01:42:0f:c1:24:06:5c:f6:06:3c:45:3a:
37:c0:3e:0a:ee:cb:44:aa:d3:a9:74:d0:e2:77:30:d4:0a:8b:
13:73:ba:a6:a2:3b:02:f0:60:fa:6e:27:20:d1:3d:23:64:38:
4d:54:36:c5:20:04:d1:2e:68:6d:5c:30:af:ef:5a:a5:7f:a5:
06:c2:f7:51:40:ec:14:c7:1d:bc:45:7f:fe:77:02:50:aa:37:
19:9d:2c:02:74:a3:56:e5:d4:36:e9:c0:33:bc:c8:52:e2:c8:
1e:21:26:83:cb:e3:b6:72:55:df:1e:dc:48:7b:d8:1a:ca:2a:
21:4f:eb:94:9f:de:82:f8:5b:82:0d:ef:d5:e9:89:99:b4:48:
ce:d5:9e:a4:ca:3b:c9:e1:19:a5:60:ec:04:36:31:11:b0:31:
7a:22:64:9c:6e:dd:82:e4:65:96:a2:e3:aa:9c:99:ec:f5:e1:
48:84:7c:f5:38:00:cb:24:cf:5d:ed:e5:87:a9:86:c5:cb:4f:
65:6a:35:21:2e:30:cd:e6:85:84:13:e3:ff:9c:72:4d:a8:9c:
fb:63:01:eb:a8:ae:6f:84:66:b8:bd:fe:0f:c9:17:96:8d:42:
9d:8c:0c:bc:90:ab:17:19:df:6f:6a:28:fc:8c:50:6d:88:69:
31:75:6e:d7:6d:f2:f4:70:f0:64:14:c2:fc:57:dc:f3:68:57:
9d:4c:fe:94:e5:13:d7:9f:ad:ee:68:1b:df:9c:af:bb:f4:73:
83:d6:0a:54:fa:73:ec:02:f2:f2:87:35:7c:2a:58:df:20:32:
1a:c2:c2:ba:1d:4f:5f:8c:fe:3c:7e:e7:0c:80:0e:27:57:c2:
01:48:1f:58:f7:2c:f3:b7
And for the certificate itself:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d7:9b:09:48:1f:62:44:95:80:ef:b7:e4:5c:e1:c7:4b
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=*.node.consul/emailAddress=ecoan@instructure.com, O=Instructure, OU=Ops, C=US, ST=UT, L=SLC
Validity
Not Before: Jan 1 18:41:57 2018 GMT
Not After : Jan 1 18:41:57 2021 GMT
Subject: CN=i-02da590eb53768ddc.node.consul/emailAddress=ecoan@instructure.com, O=Instructure, OU=Ops, C=US, ST=UT, L=SLC
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:aa:77:6d:61:52:be:92:78:b6:b2:82:41:93:08:
86:ba:00:e3:fc:d4:43:2e:3a:e6:49:f8:9d:dc:e5:
40:f3:18:18:ac:56:ae:a1:96:b6:ff:35:63:97:8b:
9b:a7:cc:c0:f3:7b:99:82:8e:4c:cf:d4:25:56:c2:
32:2f:35:08:5f:79:ee:ea:52:02:2b:2f:11:ac:10:
ea:18:e7:00:b6:52:ee:df:c7:01:7a:68:7e:32:1c:
63:73:77:43:99:a0:a6:13:05:26:39:e2:4d:b9:e6:
c1:58:99:02:dc:0c:99:90:1f:d4:79:9e:fe:77:99:
58:a7:a7:26:42:9e:13:34:f3:e9:c2:f2:3a:6f:72:
33:55:ad:66:89:4a:39:4b:c9:67:a8:d2:8e:80:75:
42:c9:01:9e:e7:d0:b1:7a:63:f5:6b:f1:a4:66:be:
d9:e5:e9:87:4c:2e:99:87:0f:26:1f:2c:19:25:78:
82:fe:31:e2:26:6f:de:0d:93:75:65:7f:cc:c9:a3:
24:69:db:7b:57:57:fa:49:ec:39:8c:ac:92:2f:1c:
cc:3d:e4:e2:6c:48:4b:bb:35:20:74:77:91:80:ad:
7d:9d:9f:7b:53:7c:bf:98:bb:a6:27:15:de:aa:27:
e3:8b:87:3b:35:50:ac:6d:36:ba:2b:95:b5:4b:2b:
ce:6b:84:91:e0:4d:e0:21:fd:d3:80:43:17:98:ff:
66:b8:7f:32:f9:ed:d3:25:a3:6f:b4:e9:26:56:4c:
c3:d8:2f:2f:6e:f8:9a:85:4d:a9:05:d2:f5:60:1d:
42:df:29:75:1b:2c:66:b1:a4:56:8a:0b:43:14:b8:
7d:62:4d:5a:1b:a6:a1:da:98:64:4e:e2:e2:8b:8d:
c9:57:f9:7d:58:91:12:d7:dd:7b:52:7c:00:91:bc:
ab:25:a0:63:91:8c:02:c8:8f:7e:23:80:33:95:b2:
4a:ea:f9:ee:87:1a:17:f1:85:60:ae:db:f1:d3:63:
ab:0b:d8:ab:7c:56:90:8f:f5:9a:60:25:2b:81:b5:
df:bc:f7:0d:9c:47:8a:b6:4d:2b:88:21:cf:bd:d5:
fe:1a:d7:76:19:03:06:d1:9b:67:42:f9:8f:be:27:
61:9f:a8:9c:2a:57:96:e1:a2:d8:84:7f:9f:15:bb:
b2:ae:21:92:7a:4c:42:69:10:63:da:bf:b6:eb:74:
57:13:6f:d9:c2:a9:99:09:09:b5:d6:ff:e0:c4:eb:
91:bf:4d:9e:98:3e:e3:8c:69:7a:06:01:f7:d0:75:
df:d2:6e:78:b2:39:6a:73:70:41:dd:30:f5:00:c0:
f6:70:d3:63:76:98:01:ee:52:4a:92:77:39:c5:ab:
99:33:97
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Key Identifier:
AA:C7:CB:B6:22:D2:EF:05:72:89:92:DF:2E:44:6B:D5:33:00:D8:06
X509v3 Subject Alternative Name: critical
DNS:i-02da590eb53768ddc.node.consul
Signature Algorithm: sha256WithRSAEncryption
ab:dc:ad:f4:55:af:a6:ca:27:d2:7a:f6:77:b3:4f:1d:14:41:
7c:56:3a:a0:75:de:1f:0a:3c:7f:50:d0:4d:b0:1b:01:75:4c:
d0:19:c7:5d:86:c5:ac:85:10:9e:58:22:87:23:70:27:a5:75:
11:73:6f:2f:8e:f3:90:ca:51:c7:cb:75:46:59:91:3f:d3:f3:
dd:d4:60:4d:60:e1:82:a9:c6:e8:ac:3e:01:9d:4d:b8:cb:70:
90:2a:f6:58:ba:dd:44:67:e7:7e:71:70:cc:fc:5a:7e:1e:e4:
32:e4:2c:43:64:79:69:32:a4:d2:12:5a:fe:3e:e3:47:b9:3d:
8d:41:16:b5:5e:d8:bd:dd:39:e8:0a:8a:ee:7d:44:fd:98:bc:
02:79:57:d5:2d:dd:f7:14:87:f5:19:29:80:27:f4:3d:6e:0d:
0a:ce:78:fd:e1:1e:b3:7e:4b:cd:07:d7:e3:4e:50:35:56:a6:
8d:ea:3d:b3:ab:99:55:54:27:22:9d:3d:7d:93:37:b6:9d:51:
5d:f1:64:69:d9:72:de:58:e2:ec:4e:c0:0e:62:77:68:13:5e:
2d:01:7b:06:ec:8a:23:bc:6f:e5:ee:b5:1d:0b:4d:08:35:6c:
49:a4:43:24:32:99:ad:fd:34:44:24:ba:49:f7:79:28:0e:88:
cb:72:9b:ce:c4:9d:fc:e1:5f:3c:d9:f5:18:ae:e9:f4:4a:52:
72:03:cb:77:23:0d:9b:63:9a:1f:66:fe:6e:f1:78:87:85:80:
93:39:d7:59:dd:7b:4b:c5:b2:13:7b:f5:ab:78:ac:32:cf:b1:
b6:2b:08:5f:ba:46:fd:50:82:48:62:81:e6:9d:77:05:25:53:
40:c1:6d:8b:b2:89:5f:fb:6e:f9:d3:69:e7:d6:f8:7c:5e:72:
0a:19:d5:bc:ec:4f:f3:91:38:cc:88:58:f1:19:0b:08:8a:76:
45:c8:3f:30:52:ff:8c:83:01:5e:c8:f7:41:ee:38:13:db:ce:
9b:86:a3:0b:a3:3d:48:d1:03:2c:ab:6f:1c:b1:46:67:70:13:
64:99:c3:37:21:af:4d:ce:0a:28:9c:94:67:89:d4:04:5d:a2:
56:fa:e0:bb:82:5f:75:d4:a5:22:a7:57:53:dc:cb:f1:65:e3:
df:b6:66:a2:88:39:25:09:b5:84:a8:5b:a7:76:89:a1:46:7b:
16:d3:df:7f:ab:a2:41:c1:cb:0b:75:98:8c:d6:67:fd:5b:4a:
ad:50:a9:e0:af:5c:f3:28:a0:aa:80:62:f5:77:4d:17:d4:6a:
3f:2a:6a:59:47:c4:b1:88:36:f6:55:f2:32:84:6b:70:78:3a:
d2:b4:13:53:e2:1c:e8:ef
I assume this is probably due to something in the way I’ve generated the certificates, but I’m not really sure where to check. As it’s my understanding error 20 unable to lookup local issuer certificate happens when it can’t find a particular cert in the chain. However, I’m not sure why it can’t find the full info it needs.
Quick step by step to fix SSL certificate problem: Unable to get local issuer certificate error.
Have you experienced the ‘SSL certificate problem unable: to get local issuer certificate’ problem while attempting to move from HTTP to HTTPS? We know how overwhelming it can be to deal with this issue but don’t let that frighten you. Here, we can help you fix it with this piece of writing and don’t make the wrong decisions like uninstalling your SSL certificate.
Regardless of which error pops up or the complexities involved in fixing it, never uninstall your SSL Certificate to get rid of SSL errors as doing that could prove to be fatal and expose you to serious security risks. Always remember that your SSL certificate protects the communication exchanged between the server and the browser, which prevents data interception of a third party.
Even, data privacy laws are getting stricter by the day, and therefore, you cannot make the unwise decision to uninstall your SSL. So, your only option is to get to the bottom of the ‘unable to get local issuer certificate’ error and fix it.
Before we help you do that, let us figure out how an SSL Certificate works and why it shows up the ‘curl: (60) SSL certificate problem: unable to get local issuer certificate’ or the ‘git SSL certificate problem unable to get local issuer certificate’ errors.
Why SSL Certificate Problem: Unable to get Local Issuer Certificate Error Happen?
Your SSL certificate’s primary purpose is to confirm authentication and ensure a secure exchange of information between the server and the client by referring to the HTTPS protocol. That is only possible when you have a working root certificate that is either directly or indirectly signed by a Certificate Authority. However, the error unable to get local issuer certificate’ occurs when the root certificate is not working properly especially when an SSL client makes an HTTPS request and during this, the client has to share an SSL certificate for identity verification.
Therefore, you need to take the necessary actions required to help bridge the gap.
How to Fix SSL Certificate Problem: Unable to get Local Issuer Certificate?
Now that we know the reasons for the ‘unable to get local issuer certificate’ glitch, it’s time to act. You could be experiencing this glitch due to many reasons, and those reasons could vary from software interfering in the SSL/TSL session or your Git application. Once you identify the cause, it becomes a whole lot easier to fix it. If you are unable to do that, then we recommend that you try out all the fixes one after another and something will work.
Unverified Self-signed SSL Certificate
Anyone can sign an SSL certificate by generating a signing key; however, the OS and the Web Browser may not be able to identify that. This could be the reason why you see the ‘SSL certificate problem: unable to get local issuer certificate’ or the ‘curl: (60) SSL certificate problem: unable to get local issuer certificate’ error.
Solution – Buy an SSL Certificate that is authenticated by a reputed certificate Authority and install it.
Alter the php.ini file to solve ‘unable to get local issuer certificate’
Log in to your web control panel such as cPanel and locate the file manager. You will then find the PHP software, and inside that, you can find the php.ini file that you need to edit. Follow the below-mentioned steps.
Change Php.ini
- Click on http://curl.haxx.se/ca/cacert.pem and download cacert.pem.
- After that, copy cacert.pem to openssl/zend, like ‘/usr/local/openssl-0.9.8/certs/cacert.pem’.
- Finally, navigate to the php.ini file, modify CURL. Add “cainfo = ‘/usr/local/openssl-0.9.8/certs/cacert.pem’” to modify it.
- Restart PHP
- Confirm if CURL can now read the HTTPS URL.
Without Altering php.ini file
Use the code given below:
$ch = curl_init();
$certificate_location = ‘/usr/local/openssl-0.9.8/certs/cacert.pem’;
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, $certificate_location);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, $certificate_location);
Git Users
Most Git users experience the ‘SSL certificate problem: unable to get local issuer certificate’ or the ‘git SSL certificate problem unable to get local issuer certificate’ error at some point in time. If you have encountered it, then there are two ways of solving this — the first one is a permanent fix and the second one is a temporary fix, which we shall discuss below.
Permanent Fix
If you are a Git user-facing the ‘git SSL certificate problem unable to get local issuer certificate’ error, then you need to tell Git where the CA bundle is located.
To help Git find the CA bundle, use the below-mentioned command:
git config –system http.sslCAPath /absolute/path/to/git/certificates
Temporary Fix
To temporarily fix the ‘SSL certificate problem: unable to get local issuer certificate’ error, you could disable the verification of your SSL certificate. However, we recommend that you use it sparingly as it could lower your website’s security.
Use the following command to disable the verification of your SSL certificate:
git config –global http.sslVerify false
If neither of the two options work, consider removing and reinstalling Git.
Conclusion:
We are confident that one of the above ‘SSL certificate problem: unable to get local issuer certificate’ error fixes would work for you. Finally, we strongly recommend that you entirely avoid removing your SSL certificate. Your website needs to be protected, and one of your most robust defenses is an active SSL certificate.
Related SSL Errors:
- ERR_CONNECTION_REFUSED
- Secure Connection Failed in Firefox
- NET::ERR_CERT_AUTHORITY_INVALID
- ERR_SSL_VERSION_INTERFERENCE
- ERR_SSL_PROTOCOL_ERROR