tl;dr:
Will old boto versions that don't include amazon trust services certs become obsolete in a few months when amazon migrate from DigiCert to Amazon Trust Services?
Amazon's CA for S3 is changing from DigiCert to Amazon Trust Services in a few months.
They say clients should trust Amazon Trust Services’ root certificates (Having them listed in their trust store).
curl and chrome respond well to test endpoints by AWS that test that everything's trusted properly, meaning the root certs are within the trust store in the OS, but I gotta make sure Botocore 1.8.11, and boto 2.38 trust as well.
Why would they be any different? because of this:
The .NET, Java, PHP, Go, JavaScript, and C++ SDKs and CLIs do not bundle any certificates, so their certificates come from the underlying operating system.
More recent versions of botocore and boto3 DO have the root certs bundled with them (e.g.),
Does that mean the versions I'm using, who do not have the certs bundled, will be obsolete in a few months? or did they also use the underlying OS trust store before having the certs bundled?
Is using those boto versions to fetch an object from an already migrated region such as eu-west-3 means I'm absolutely safe?
Of course, upgrading is what one should do, but that's a very hard work in my situation.
The bundled boto3 and botocore root certificates are just a fall-back for when the root certificates aren't present on the OS.
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -e "Amazon Root CA" -e "Starfield"
Should find the root certs, meaning all's good:
subject= /C=US/O=Amazon/CN=Amazon Root CA 1 subject= /C=US/O=Amazon/CN=Amazon Root CA 2 subject= /C=US/O=Amazon/CN=Amazon Root CA 3 subject= /C=US/O=Amazon/CN=Amazon Root CA 4 subject= /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority subject= /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 subject= /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
Yes.
Related
This question already has answers here:
SSL working in chrome but sometimes in Firefox and not on IOS, Android or Blackberry
(2 answers)
Closed 1 year ago.
I've put together a Linux (Centos 7) server to serve eye-n-sky.net.
Serving content from that site to browsers on Win10 and Linux systems works beautifully. However, when I use openssl to access the site,
openssl s_client -connect eye-n-sky.net:443
the site certificate is rejected,
Verify return code: 21 (unable to verify the first certificate)
I've concluded that the way a browser verifies the certificate is different from what openssl does. Am I on the right track?
I've tested this on three different openssl instances (Debian, Centos, FreeBSD) and have consistent results.
Openssl as a client to other sites, e.g. www.godaddy.com, microsoft.com, work fine, being able to verify the certificate against the installed CA chain.
Believing that I was missing a CA cert, I used the -CAfile option to specify the possibly missing cert, to no effect.
What am I missing? I'm guessing that openssl has a stricter verification discipline, but I don't know where that gets configured.
Thanks,
Andy
Summary: yes, eye-n-sky was providing only it's cert when it needed to include the intermediate and root certs.
However, it took me forever to figure out that my Apache version did not support including the chain in the server cert file. Instead, I had to provide the chain file separately in an SSLCertificateChainFile directive.
OpenSSL's command-line s_client utility has nothing built in to validate the server's certificate. Browsers have a built-in list of trusted certificates to verify the server certificate against.
You have to supply the trusted certificates using options such as -CAfile file or -CApath directory. Per the OpenSSL 1.1.1 s_client man page:
-CApath directory
The directory to use for server certificate verification. This
directory must be in "hash format", see verify(1) for more
information. These are also used when building the client certificate
chain.
-CAfile file
A file containing trusted certificates to use during server
authentication and to use when attempting to build the client
certificate chain.
Note the use of words such as "certificate chain". If you go to godaddy.com you'll see that the server's cert is for *.godaddy.com, but it was signed by Go Daddy Secure Certificate Authority - G2, and that intermediate certificate was signed by Go Daddy Root Certificate Authority - G2 - a different certificate. There's a total of three certificates in that chain.
Verify return code 21 is "no signatures could be verified because the chain contains only one certificate and it is not self signed", so if your CA file only had the certificate from Go Daddy Root Certificate Authority - G2 and not the one from Go Daddy Secure Certificate Authority - G2, OpenSSL would see from the server's cert itself that it was signed by Go Daddy Secure Certificate Authority - G2 and could go no further - it doesn't have that cert to see who signed it.
I have two MQTT server environments: PROD and PILOT. These environments each have their own separate certificate authorities. I have one client which can use either CA certificate to connect to each environment. Is it possible to combine these two CA files into a single file so that the CA file need not be changed in the client when I change the environment?
Sample client:
mosquitto_sub -h server.com --cafile /path/to/ca.file
Please note that the CA files contains intermediate CA as well. Please refer another post where I mention this.
From the man page:
--cafile
Define the path to a file containing PEM encoded CA certificates that are trusted. Used to enable SSL communication.
Note the certificates in plural form :-)
Your file should only contain trust-anchors - the Root CA certificates. The other certificates in the chain should be sent by the server. You should consider reconfiguring your server so that the whole chain is sent in line with the TLS protocol (read certificate_list here).
While it often works, placing intermediate certificates in the trust-anchors store doesn't help matters. If you were to renew the intermediate (which happens more often than the root) then you will need to replace the intermediate in all your clients. Might not be an issue in your case, but in the real-world that is a major headache. Also, depending on the libraries used and how the developers wrote the client, it may not check revocation of the intermediate if it is used as a trust-anchor.
The file pointed to by --cafile should be a concatenation of PEM encoded Root CA certificates.
I am trying to obtain the root certificate of various websites for my project, but I am not sure the certificates that I am getting back with this command, contains root certificate or not?
openssl s_client -showcerts -connect google.com:443
I was searching for an answer when I came across a post where wget was used to get the root certificate from the certificate repository of godaddy
wget https://certs.godaddy.com/repository/gd_bundle.crt -O ~/.cert/mail.nixcraft.net/gd.pem
how do i find the repository for every website?
The server must include the certification chain during TLS connection (https). The chain may include the CA root certificate, but it is optional, So you have no guarantee that it will be available. The TLS protocol expects the client to have the certificate in their truststore to verify the trust
You can download the server certificate of every site programmatically, but it is needed to look for the root CA certificate. As you can see, godaddy publish them in its website. In many cases the certificate itself includes a reference to download the root certificate
A
/ \
B C
| |
D E
when E (or C) is verifying D's certificate he needs to trust B also.
is there a way to avoid having to explicitly add B's cert to E's CA store?
using openssl, is there the way to automate the retrieval of B's cert either from the client or another source (maybe a field like issuerDistributionPoint in D's certificate)?
is there a way to avoid having to explicitly add B's cert to E's CA store?
The common way is to send all intermediate certificates along with the leaf certificate inside the TLS handshake. For instance if you connect to google.com you get the following certificate chain provided by the server within the TLS handshake:
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Using the intermediate certificates (1,2) the client then can build the trust chain from the leaf certificate (0) up to the locally stored trusted CA (/C=US/O=Equifax/OU=Equifax Secure Certificate Authority in this case).
Of course you might also add the intermediate certificates as trusted in the clients. But since there are a lot more which also change more often than the trusted root certificates you would need a bit more memory but you would also update your clients regularly with the new intermediate certificates.
using openssl, is there the way to automate the retrieval of B's cert either from the client or another source (maybe a field like issuerDistributionPoint in D's certificate)?
openssl does not provide specific tools to deal with this. The desktop browser Google Chrome will actually try to download missing intermediate certificates from the internet, probably based on the information in the Authority Information Access part of the certificate. But I'm not aware of other browsers (apart from other Chromium derivates like Opera) doing this.
I just installed an SSL on Plesk, and when I go to https://www.example.com in Chrome, I get the error below:
This CA Root Certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities Store.
Sort of defeats the purpose of having an SSL. Any idea how I can make this message go away?
I bought the SSL from GoDaddy, which I would expect to be a trusted authority.
This issue 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 (GoDaddy) provides a bundle of chained certificates that should be chained with the server certificate to address this issue of lack of trust. Unfortunately, GoDaddy does not provide any documentation on this front. You should have received two different certificates from GoDaddy, one for your server, and the bundle. Depending on your server, this is what the configuration would look like:
For Apache:
Specify each certificate in its own directive:
SSLCertificateFile /path/to/cert/www.example.com.crt
SSLCertificateChainFile /path/to/cert/bundle.crt
For Nginx, documented here:
Both certificates should be concatenated, first the server, then the bundle:
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
And then use www.example.com.chained.crt in your server ssl_certificate directive:
ssl_certificate www.example.com.chained.crt
GoDaddy is recognized on Windows operating systems, because the GoDaddy root certificate is pre-installed on Windows. But GoDaddy will not be automatically recognized in many contexts and would need to be manually configured by users (which is not a trivial task). IPhone, for example, will not trust GoDaddy certificates out of the box. You may consider getting certificate from established certificate authorities such as Verisgn or Thawte, but they will be more expensive.
#John: GoDaddy is a registrar/webhost, I believe their certificates are just reseller certs. You don't need to go expensive to get compatibility as #Jaro suggests. I've deployed several RapidSSL certificates that are recognized by Chrome/iOS and Safari/iOS without user intervention and are much cheaper than the higher-insurance certificates like Symantec/VeriSign.
The only way to make that message go away, is by buying a real certificate from a trusted authority.