I am trying to create a full-chan(bundle) cert, from the base certs provide by Komodo. I can get the certificate to work, but when I validate using www.ssllabs.com, it gives me this warning <
chain issues: "Incorrect order, Extra certs, Contains anchor"
These are the provided certs and the notes from Komodo:
# Root CA Certificate - AddTrustExternalCARoot.crt
# Intermediate CA Certificate - USERTrustRSAAddTrustCA.crt
# Intermediate CA Certificate - GlobeSSLDVCA.crt
# Your Globe Standard Wildcard SSL Certificate - STAR_example_com.crt
tree .
├── certs
│ ├── AddTrustExternalCARoot.crt
│ ├── GlobeSSLDVCA.crt
│ ├── STAR_example_com.crt
│ └── USERTrustRSAAddTrustCA.crt
And this is how I have created the bundle which gives me the error/warning:
cat certs/STAR_example_com.crt \
certs/GlobeSSLDVCA.crt \
certs/USERTrustRSAAddTrustCA.crt \
certs/AddTrustExternalCARoot.crt \
>> httpbin.example.com.crt
From the reading I have done it seems this is the correct process, but obviously not:
Domain cert
Intermediate cert 1 above domain
Intermediate cert 2 above that and so on
Root cert
Any help would be appreciated, as I am usually just provided with a full-chain to use.
Cheers in advance
All good I ended up working it out. But feel free to correct me if I am wrong. That pattern suggested was correct with the only difference being to exclude the "root" certificate from the "bundle". There is a bit of conflicting advice on this but, it now passes the ssl test with no warnings.
cat certs/STAR_example_com.crt \
certs/GlobeSSLDVCA.crt \
>> httpbin.example.com.crt
Related
The cert that is stored in /etc/ssl/cert.pem expired today on my Mojave computer, which has caused problems with my curl commands. Is there anyway to update it? I see that my Catalina computer has a newer certificate. Can I just copy it over to my Mojave computer?
Yesterday, the Let's Encrypt DST Root CA X3 root certificate expired, which is causing similar problems as you experienced: curl displays a SSL certificate problem: certificate has expired error when trying to access websites using the new Let's Encrypt ISRG Root X1 certificate.
On macOS Mojave (and maybe others, but this is what I use), the default curl uses certificates in /etc/ssl/cert.pem when verifying TLS connections (you can confirm this by by running curl -v https://example.com 2>&1 | grep CAfile).
The simplest fix is to delete the expired root certificate from the /etc/ssl/cert.pem file, assuming its replacement already exists in the file. This is enough to fix the expired DST Root CA X3, because its replacement, ISRG Root X1 already exists in the /etc/ssl/cert.pem file. Delete all lines from ### Digital Signature Trust Co. to -----END CERTIFICATE-----.
If you need to completely replace /etc/ssl/cert.pem with updated certificates, you can replace it with certificates exported from the macOS System Roots keychain:
Make a backup of the old /etc/ssl/cert.pem:
sudo cp /etc/ssl/cert.pem{,-orig}
Export system keychain and replace contents of /etc/ssl/cert.pem:
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain | sudo tee /etc/ssl/cert.pem >/dev/null
Alternatively, you can tell curl to use a different certificate file like this:
curl -I --cacert /path/to/certificates.pem https://example.com/
Or configure the location of this file using the CURL_CA_BUNDLE=/path/to/certificates.pem environment variable.
For Mojave in 2022/02, here is a simple solution:
Backup the current version of /etc/ssl/cert.pem in your macOS.
Download the new CA certificate( officially recommended by curl.se), renaming it to cert.pem.
Replace the original one with the new one: sudo mv cert.pem /etc/ssl/cert.pem.
I think you have problem with AddTrust CA
What You Need to Do
For most use cases, including certificates serving modern client or server systems, no action is required, whether or not you have issued certificates cross-chained to the AddTrust root.
As of April 30, 2020: For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly.
https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
I tried Quinn Comendant's solution, but it didn't work.
I ended up solving this by installing OpenSSL and linking the cert.pem file to the one under OpenSSL (in MacOS Mojave):
$ sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.bak
$ brew install openssl
$ brew info openssl
openssl#3: stable 3.0.0 (bottled) [keg-only]
Cryptography and SSL/TLS Toolkit
https://openssl.org/
/usr/local/Cellar/openssl#3/3.0.0 (6,415 files, 28MB)
Poured from bottle on 2021-10-04 at 11:13:17
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/openssl#3.rb
License: Apache-2.0
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
/usr/local/etc/openssl#3/certs
...
From this we'll know the config is in /usr/local/etc/openssl#3, then:
$ sudo rm /etc/ssl/cert.pem
$ sudo ln -s /usr/local/etc/openssl#3/cert.pem /etc/ssl/cert.pem
This solved my problem.
Thus far, the only working solution I can find is to just upgrade to Catalina. None of the above suggestions work because even Homebrew is broken because most of their mirrors use Let's Encrypt certificates. Adding a new ISRG Root X1 certificate file from http://x1.i.lencr.org/ to the system keychain and exporting to a new /etc/ssl/cert.pem doesn't even fix the problem.
We are using Puppet to configure multiple clusters running Apache HTTPD using the Apache module from Puppetlabs.
All certificates are stored in a git repository Puppet has already access to (e.g. puppet://files-host/path/to/certs/${fqdn}.crt).
Right now we have to explicit specify the intermediate CA certificate (ssl_chain variable in the apache class) for each used certificate.
Is it possible to let Puppet automatically find out the correct intermediate CA certificate? In a "real" scripting language I would iterate over all *.pem files and compare the subject with the issuer of the certificate. But how could that work in Puppet?
We do not want to embed the intermediate CA certificate into all certificates.
I've got a solution for my problem. It's not the optimal way, but it seems to be the only one in case of a Puppet managed infrastructure.
All intermediate CA certificates are located in a single directory in the git repository and Puppet will put the whole content of the folder to the managed hosts (set the "recursive" and "purge" attributes of the file resource to true).
Each certificate and key file is also deployed using file resources. The file resource for the certificate file will notify an exec resource executing a shell script which symlinks the right CA certificate to a static file path (i.e. /etc/ssl/private/my-domain.pem -> /etc/ssl/ca/some-ca.pem. So there are three files for each FQDN (fqdn.crt, fqdn.key and fqdn.pem).
I have a Meteor app I am deploying to a Digital Ocean Ubuntu server via MUP. It works great without SSL, but I can't figure out the SSL part.
I Purchased a Comodo SSL Cert. They sent me 4 .crt files. I can the following command:
cat cert1.crt cert2.crt cert3.crt mydomain.crt > ssl.pem
I then put that ssl.pem file in the root directory locally. Added "ssl": {"pem":"./ssl.pem"} to my mup.json file and ran mup setup -- everything is succesful until:
[45.55.225.190] x Verifying SSL Configurations (ssl.pem): FAILED
-----------------------------------STDERR-----------------------------------
Trying to initialize SSL contexts with your certificatesError loading rsa private key
-----------------------------------STDOUT-----------------------------------
----------------------------------------------------------------------------
I'm not even sure how to troubleshoot this. I ran a quick find on the server and the ssl.pem is there, so mup successfully sent the file over, but it seems stud is not verifying the file or not finding it?
Turns out I was running into two different problems. First, you have the put the certificate files in a very specific order. Second, I was not including my key file. The command to create the .pem file needed was:
cat mydomain.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt mydomain.nopass.key > ssl.pem
This blog post at DeveloperSide.NET helped me tremendously.
I am running openvpn on an Ubuntu 14.04 box. The setup was fine until an OpenSSL upgrade, then when I try to create new client cert with easy-rsa, I got this message:
root#:easy-rsa# ./pkitool onokun
Using Common Name: onokun
Generating a 2048 bit RSA private key
.+++
........+++
writing new private key to 'onokun.key'
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
Error Loading extension section usr_cert
3074119356:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=CA_default name=email_in_dn
3074119356:error:2207507C:X509 V3 routines:v2i_GENERAL_NAME_ex:missing value:v3_alt.c:537:
3074119356:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:93:name=subjectAltName, value=onokun
This problem is different from a reported bug that the which opensslcnf script can not find an matching version of openssl.cnf to use (above message shows openssl-1.0.0.cnf). I performed a Google search but did not find an answer.
Here are some environment information:
## openvpn
OpenVPN 2.3.2 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 4 2014
Originally developed by James Yonan
## openssl
OpenSSL 1.0.1f 6 Jan 2014
## dpkg --get-selections | grep ssl
libgnutls-openssl27:i386 install
libio-socket-ssl-perl install
libnet-smtp-ssl-perl install
libnet-ssleay-perl install
libssl-dev:i386 install
libssl-doc install
libssl0.9.8:i386 install
libssl1.0.0:i386 install
openssl install
ssl-cert install
What should I look at to solve this? Thanks,
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
Error Loading extension section usr_cert
I don't have a /etc/openvpn/easy-rsa/openssl-1.0.0.cnf, so take this with a grain of salt...
opensslconf.h from OpenSSL's distribution does include that section:
openssl-1.0.1h$ grep -R usr_cert *
apps/openssl-vms.cnf:x509_extensions = usr_cert # The extensions to add to the cert
apps/openssl-vms.cnf:[ usr_cert ]
apps/openssl.cnf:x509_extensions = usr_cert # The extensions to add to the cert
apps/openssl.cnf:[ usr_cert ]
Can you restore an old version of /etc/openvpn/easy-rsa/openssl-1.0.0.cnf?
Here's the section from apps/openssl.cnf. You might consider adding it to Easy RSA's configuration file if its missing. First, try an empty section. Then try adding the original code back.
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
By comparing an earlier Ubuntu 14.04 install that did not have this problem, it seems the specific issue is with "subjectAltName". I didn't read up on what this does, but the command below will fix your "openssl-1.0.0.cnf" file:
perl -p -i -e 's|^(subjectAltName=)|#$1|;' /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
I should probably file a bug report.
I finally got his working (on my machine) Firstly my setup is a little different, I'm on Windows10, running OpenSSL 1.0.2h. I'm trying to generate multiple certificates, CAs and other things for tests, I am getting the error:
configuration file routines:NCONF_get_string:no value:.\crypto\conf\conf_lib.c:324:group=CA_default name=email_in_dn
To fix it I found placing the entry email_in_dn = no in CA_Default openssl.cfg section as bellow
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/caprivkey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
email_in_dn = no # <-- fixes CONF_get_string:no value
I hope this helps someone else.
This is filed as a bug in Ubuntu. See SSL certificate creation crashes without subjectAltName.
The work-around described by Yuriy seems to work (copied from launchpad):
in the file /usr/share/easy-rsa/pkitool
just replace expressions:
KEY_ALTNAMES="$KEY_CN"
to:
KEY_ALTNAMES="DNS:${KEY_CN}"
In my version of the file this is line 284, just after the string "Using Common Name"
To get rid of this error:
3074119356:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=CA_default name=email_in_dn
use
-noemailDN
in the openssl command.
For example:
$ openssl ca -batch -config openssl.cnf -extensions usr_cert -noemailDN -days 375 -notext -md sha256 -in csr/www.example8.com.csr.pem -out certs/www.example8.com.cert.pem -verbose -passin pass:changeit
I'm trying to connect with MailChimp's API, but keep getting errors:
Error. API call to lists/list failed: SSL peer certificate or SSH
remote key was not OK
Then, I created a cacert.pem file and set it in the Mailchimp.php file:
$this->ssl_cainfo = ROOT . DS . 'cacert.pem';
And get this:
Error. API call to lists/list failed: SSL certificate problem, verify
that the CA cert is OK. Details: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
or
Error. API call to lists/list failed: SSL peer certificate or SSH
remote key was not OK
Per this page:
I tried using the http://curl.haxx.se/docs/caextract.html file for my cacert.pem file, but that gives the "not OK" error listed above.
I also tried making my own with the info provided by our host (a text file, changed extension to .pem, and pasted one and/or both chunks of data into it, making it look like this):
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
or just one:
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
At a loss for where to go from here, what to try...etc
Using the example code from here: https://github.com/mailchimp/mcapi2-php-examples
And getting the Vendor files via composer:
"require": {
"mailchimp/mailchimp": ">=2.0.0"
},
Having spoken to MailChimp, the certificate they're still (Jan 2016) using – for compatibility reasons, they told me – is the GTE CyberTrust Global Root (note GTE was bought by Digicert), so you don't need to replace the entire bundle, just add or force PHP to read this certificate:
https://gte-cybertrust-global-root.digicert.com/info/index.html
(note you'll get an 'insecure connection' warning if you try and load that in Firefox, for hopefully obvious reasons – you can add an exception.)
It's in standard .crt format, which is what you need. Guide to certificate formats
You didn't specify what the server was but here's how to add an extra one on Linux without having to replace an entire bundle etc:
On Debian/Ubuntu, certificates live in /etc/ssl/certs/
Copy and paste the signature into a new file in that directory, e.g. mailchimp-legacy.crt
run sudo c_rehash /etc/ssl/certs - What's going on here: c_rehash calculates a short hash of each certificate and creates a symlink from that to the original .pem or .crt file. Basically it's a quick lookup table for openssl - openssl will perform the hash as well and look for the symlink, rather than having to have a database of certificate names or open every file in turn to find the right one.
check it's worked with this: ls -lh *.0 | grep 'mailchimp-legacy.crt'
You should see something like this:
lrwxrwxrwx 1 root root 20 Feb 13 14:17 4d654d1d.0 -> mailchimp-legacy.crt
lrwxrwxrwx 1 root root 20 Feb 13 14:17 c692a373.0 -> mailchimp-legacy.crt
Alternatively: On Debian, there's also a file called /etc/ca-certificates.conf and the exclamation mark in the line !mozilla/GTE_CyberTrust_Global_Root.crt indicates not to use that one. I believe it's possible to put a copy of the certificate with that name under /usr/share/ca-certificates/mozilla and run sudo update-ca-certificates, but it seems to me it be likely to be removed again when the package & config file are next updated.
Remember to remove any workarounds you were using - e.g.
- old CA bundles in your certificate directory
- anywhere you override CURLOPT_CAINFO in your PHP
- an openssl.cainfo line in your php.ini
Check your application works correctly. I didn't need to restart PHP or my webserver, the change was instant. Worth using apt-get update/upgrade to check you have the most recently certificate packages.
Here's a way to verify SSL connection (and verification) to a specific server from the command line:
echo GET | openssl s_client -CApath /etc/ssl/certs/ -connect us3.api.mailchimp.com:443 2>&1
Monitoring: (updated) MailChimp's v2.0 API (deprecated) has an endpoint called 'helper/ping' which returns some text to indicate the API status - useful as an automated test of API health and that your certificates are all still working. If you're using v3.0, they recommend using the API Root Resource and appending ?fields=account_name if you don't actually need to check any of the data.
Someone asked in the comments if this was related to Heartbleed. No. Heartbleed is an openssl vulnerability related to eavesdropping on data in RAM. Mozilla removed GTE CyberTrust (twice) because they wanted to remove all 1024-bit root certificates - research has suggested a nation state could break a 1024-bit prime.
You need the older certificates:
https://github.com/bagder/ca-bundle/blob/e9175fec5d0c4d42de24ed6d84a06d504d5e5a09/ca-bundle.crt
As defined on the page:
http://curl.haxx.se/docs/caextract.html
RSA-1024 removed
Guess Mandrill an Mailchimp use a RSA-1024 version.
That is the one you need. I had the same issue.
Debian and other operating systems and browsers have removed 1024-bit certificates because they are no longer considered secure. But Mailchimp has not switched to a higher-security certificate yet. Therefore you will have to manually re-add the old certificate to you system.
On debian, the correct solution is to follow the instructions in Alternative chain verification failure after 1024b root CAs removal:
First, Go to GTE CyberTrust Global Root and copy the Certificate: section (include -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. Paste it into the file
/usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt with this command: cat > /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt.
Check that it's good with the command: openssl x509 -in /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt -text -noout
To enable that certificate, add this line to /etc/ca-certificates.conf: mozilla/GTE_CyberTrust_Global_Root.crt
Update debian's certificates: update-ca-certificates
In your AppController, when you are creating a new Mailchimp instance, you can actually pass the following options:
'ssl_verifypeer'
'ssl_verifyhost'
'ssl_cainfo'
These get mapped to Curl when Mailchimp is requesting data.
So to start with, I'd try modifying line 44 of AppController to look something like this:
$this->mc = new Mailchimp('yourAPIKey', array('ssl_verifypeer' => false)); //your api key here
This will allow you to verify that it's the peer certificate that is causing issues. Of course I don't recommend that you consider this a valid solution for production, it's just a troubleshooting step.