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. crt.sh | example.com ), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:dev.spandesk.com
I ran this command:dev.spandesk.com -CAfile /etc/letsencrypt/live/dev.spandesk.com/fullchain.pem -caname root
sudo openssl pkcs12 -export -chain -in /etc/letsencrypt/live/dev.spandesk.com/cert.pem -inkey /etc/letsencrypt/live/dev.spandesk.com/privkey.pem -out dev.spandesk.p12 -name dev.spandesk.com -CAfile /etc/letsencrypt/live/dev.spandesk.com/chain.pem -caname root
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I can't reproduce your error, both commands work perfectly when I substitute your certificate paths to a Let's Encrypt cert of my own. Only when I change fullchain.pem or chain.pem (both work here) for cert.pem, it gives your reported error. But that's obviously incorrect and not what you tried.
What's the output of the following command?:
openssl verify -CAfile /etc/letsencrypt/live/dev.spandesk.com/chain.pem /etc/letsencrypt/live/dev.spandesk.com/cert.pem
$ sudo openssl verify -CAfile /etc/letsencrypt/live/dev.spandesk.com/chain.pem /etc/letsencrypt/live/dev.spandesk.com/cert.pem
$ sudo openssl verify -CAfile /etc/letsencrypt/live/dev.spandesk.com/fullchain.pem /etc/letsencrypt/live/dev.spandesk.com/cert.pem
It seems there's something wrong with your files, that should have produced the output:
/etc/letsencrypt/live/dev.spandesk.com/cert.pem: OK
Can you provide the output of ls -l /etc/letsencrypt/live/dev.spandesk.com/ and also the contents of the files cert.pem, chain.pem and fullchain.pem? Note that those three files are public knowledge, however privkey.pem is obviously not and you should never share its contents. However, the three I mentioned earlier can be shared without problems (the cert is already published in certificate logs and the chain is a public cert from Let's Encrypt, maybe just the incorrect one.)
If I may guess your cert.pem actually has the contents of chain.pem looking at the issuer.
$ sudo ls -l /etc/letsencrypt/live/dev.spandesk.com/
sudo less /etc/letsencrypt/live/dev.spandesk.com/cert.pem
sudo less /etc/letsencrypt/live/dev.spandesk.com/chain.pem
sudo less /etc/letsencrypt/live/dev.spandesk.com/fullchain.pem
Hm, cert.pem and chain.pem do look good indeed..
However, this is of course the longer chain which is in production since begin of May. My certs all have the older chain with just a single intermediate. I thought that might be the reason why the OpenSSL commands don't work, but when I run the verify command, it says "OK" here nonetheless. With the files I copy/pasted from your post! Obviously I can't try your pkcs12 command with your files
Which OpenSSL version are you using? I'm on 1.1.1k.
OpenSSL 1.0.2k-fips 26 Jan 2017
I installed openssl11 but I get the same error as above
I just booted a random virtual machine I found using Google (https://www.offidocs.com/index.php/desktop-online-utilities-apps/xlinux-online-linux ), and it just works :
~ $ openssl version
OpenSSL 1.0.1h 5 Jun 2014
~ $ cat >cert.pem <<EOF
> ^C
>
> EOF
~ $ rm cert.pem
~ $ ls
test.cert.pem test.chain.pem
~ $ openssl verify -CAfile test.chain.pem test.cert.pem
test.cert.pem: OK
(Between the cat (which didn't work..) and ls I found the file upload command of that service
So it's very weird but I don't seem to be able to reproduce your issue. The files look just fine.
I just deleted and reissued the certificate, which gave a me a longer fullchain.pem, but I still get the same error.
I just did the same thing and received the error
Osiris
May 18, 2021, 6:08pm
12
How can you get the error when you're using the same files and the same software? That's just plain weird.
Yeah, I don't get it either.
$ openssl verify -CAfile chain.pem cert.pem
$ openssl verify -CAfile fullchain.pem cert.pem
Osiris
May 18, 2021, 6:25pm
14
That's just incorrect. The issuer is R3.
What's the output of openssl x509 -noout -text <cert.pem ?
$ openssl x509 -noout -text <cert.pemCN=dev.spandesk.com
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
CA Issuers - URI:http://r3.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:dev.spandesk.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
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 5C:DC:43:92:FE:E6:AB:45:44:B1:5E:9A:D4:56:E6:10:
37:FB:D5:FA:47:DC:A1:73:94:B2:5E:E6:F6:C7:0E:CA
Timestamp : May 18 17:51:04.840 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:F3:88:EE:5A:A9:EC:71:C3:4E:90:A6:
C8:42:20:5A:23:1C:02:54:1D:CE:F6:39:72:1F:27:A2:
37:FF:91:F8:7D:02:20:49:8F:58:3C:76:A1:0B:86:C8:
9E:8F:6E:59:F4:94:24:C8:B6:3B:67:05:D5:D6:C4:F7:
E6:FB:F3:E4:86:7F:D8
Signed Certificate Timestamp:
Version : v1(0)
Log ID : F6:5C:94:2F:D1:77:30:22:14:54:18:08:30:94:56:8E:
E3:4D:13:19:33:BF:DF:0C:2F:20:0B:CC:4E:F1:64:E3
Timestamp : May 18 17:51:04.829 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:C9:2C:24:AA:BC:0B:0D:95:70:17:B1:
27:6B:38:49:17:55:D2:42:6F:9A:9C:CD:1F:19:A4:CE:
2E:45:0F:6C:24:02:20:15:6E:25:1B:37:B9:33:78:25:
A5:BE:4C:C8:87:9C:7D:A8:42:3C:1B:14:2B:94:82:FC:
1E:E9:B4:8D:AF:1E:83
Signature Algorithm: sha256WithRSAEncryption
74:0e:83:93:bf:e7:82:3d:44:18:74:0e:85:03:9e:ed:44:0d:
ee:8a:3f:04:cc:bc:27:41:8a:15:dd:21:d7:5b:31:4c:85:76:
bf:cc:f3:c7:95:31:a7:5d:cd:25:1c:3d:c9:e9:bf:75:a9:bd:
f0:10:c0:9d:6d:1a:83:f3:34:9d:f1:94:44:7e:10:c7:ed:ee:
cd:3f:17:1b:b1:92:1b:1b:04:c8:11:79:3d:39:28:21:fb:51:
a8:33:0e:12:86:ef:ac:a1:c2:13:b8:1f:37:9c:21:37:39:8b:
29:89:42:29:f5:1a:33:f8:46:b3:42:07:01:44:8e:1f:5a:69:
bc:b2:55:12:59:c8:24:5e:c2:2f:9a:11:e9:e9:18:d1:e0:22:
16:a9:bd:b9:ca:0f:cc:b7:4b:2d:32:5f:e8:11:2f:b0:ea:e8:
31:87:67:cf:12:af:85:5f:c1:de:42:9e:ab:b6:92:3e:24:dd:
55:c9:be:f0:24:5d:8f:ed:9e:98:45:71:a7:c2:86:4a:d5:2e:
61:17:3f:bc:0a:c8:6b:4a:28:60:3d:25:f1:89:5f:b2:34:6a:
22:a2:77:f5:06:19:62:7d:1f:2b:24:1c:86:76:ab:18:2b:0e:
99:ff:48:d3:3e:30:b7:e7:b4:b4:ec:92:76:70:d0:b9:08:59:
23:59:1e:3b
Osiris
May 18, 2021, 6:31pm
16
Well, maybe someone else has a brilliant idea. I'm out of them.
thanks for all your input
For me it looks like OpenSSL can't fully verify the chain, as it probably has no root certificates. You could see if installing root certs on your machine (e.g ca-certificates package) resolves the issue.
Package ca-certificates-2020.2.41-70.0.amzn2.0.1.noarch already installed and latest version
system
June 17, 2021, 7:40pm
20
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
