Okay, I recently tranfered my Comodo SSL certificate from my previous Bluehost account to my new rackspace cloud server. (LAMP stack)
Basically I just copy pasted the server cert and key and checked to make sure it was properly installed which it was. Now I am running into some issues, occasionally I will hear from people that they are getting an 'Untrusted Connection Error' while others are not getting this error at all.
Recently someone sent me a screen shot of their error and it said: This Certificate is not trusted because no issuer chain was provided.
The browser they noticed this on was safari so I cleared all my history data in safari and opened the site but I am not seeing that error.
Does anyone have any idea how to fix something like this? Thanks!
When I enter openssl s_client... i get:
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by BlueHost.Com, INC/OU=PositiveSSL/CN=www.sitename.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
You most likely lack the 'chain' or inter mediate certificates (which some people may have in their browser, and some not).
The easiest way to resolve this is by looking at the issuer details on your certificate; and finding that certificate. Then look at the issuer details of that cert - until you hit the 'root' - which is a self signed certificate (subject identical to issuer).
Once you've got them all concatenate them in a file and point SSLCertificateChainFile at that.
Your httpd.conf then looks like
SSLEngine on
SSLCertificateKeyFile .../your-key.key
SSLCertificateFile .../your-cert.pem
SSLCertificateChainFile .../ca-bundle.pem
Some CA's make this file available as a 'ca-bundle' (https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1203) when they issue a cert. Most don't.
So in that case you'll need to create it. Doing
openssl x509 -in <your cert.pem> -noout -issuer
will get you the exact issuer string. Googling for it generally gives you the intermediate cert you need (usually at the support site of your CA). Once you have that - repeat above and keep going at it until you are at the final one -- where issuer is identical to subject.
Once done - restart the webserver and that should be it.
If you want to verify you got the whole chain - then use the command
openssl s_client -connect <your domain name>:443
and check that the output starts with:
0 s:/C=GB/OU=Domain Control Validated/CN=<your domain>
i:/C=BE/O=Comodo/CN=Comodo foobar
....
3 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
and at least has one entry (3 in above example) where you have a final root; the S is identical top the i. If you just see a single entry
0 s:/C=GB/OU=Domain Control Validated/CN=<your domain>
i:/C=BE/O=Comodo/CN=Comodo foobar
and nothing more - then check your chain again - and make sure that it contains a cert with a subject identical to your issuer (in above example '/C=BE/O=Comodo/CN=Comodo foobar').
You can check this by parsing each blob in your bundle with
openssl x509 -noout -in file.pem -subject -issuer
where file.pem is one chunk of your SSLCertificateChainFile file.
Caveat: Above is a slight simplification - some Chains may have multiple roots/cross-signing. In that case it gets a bit more complex - but follows above example.
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 got valid https certificate from Let's Encrypt, but have trust issues giving it to vert.x version 3.6.2
I tested the cert with apache, it's ok, however if I try to reach the https vert.x server instance with wget I get:
$ wget https://www.myhost.mydomain/json/read/all-languages
--2019-01-22 10:30:56-- https://www.myhost.mydomain/json/read/all-languages
Resolving www.myhost.mydomain (www.myhost.mydomain)... 88.14.34.156
Connecting to www.myhost.mydomain >(www.myhost.mydomain)|88.14.34.156|:443... connected.
ERROR: cannot verify www.myhost.mydomain's certificate, issued by >‘CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US’:
Unable to locally verify the issuer's authority.
To connect to www.myhost.mydomain insecurely, use `--no-check->certificate'.
Hostname and ip is forged.
my working apache config snippet:
SSLCertificateFile /etc/certs/myhost.mydomain/cert.pem
SSLCertificateKeyFile /etc/certs/myhost.mydomain/privkey.pem
SSLCertificateChainFile /etc/certs/myhost.mydomain/chain.pem
vert.x code:
val httpsOptions = HttpServerOptions()
.setPort(443)
.setSsl(true)
.setPemTrustOptions(PemTrustOptions()
.addCertPath("/etc/certs/myhost.mydomain/chain.pem"))
.setPemKeyCertOptions(PemKeyCertOptions()
.addKeyPath("/etc/certs/myhost.mydomain/privkey.pem")
.addCertPath("/etc/certs/myhost.mydomain/cert.pem")
)
vertx.createHttpServer(httpsOptions).requestHandler(router).listen()
I set vert.x logging to debug, but no error message appears.
What am I missing?
I found the solution here: https://community.letsencrypt.org/t/android-doesnt-trust-the-certificate/16498/2
I changed the cert.pem to fullchain.pem in the setPemKeyCertOptions settings, and it works.
Thank you for your effort.
The issue is in the certificate chain file chain.pem. It seems that it does not contain the full certificate chain. If you view the file it probably contains only one intermediate LE authority cert inside, i.e., Let's Encrypt Authority X3. It works with Apache because the SSLCertificateChainFile is actually deprecated and it is not being used at all.
Vert.x on the other side does use the chain.pem file. It returns only the intermediate cert and wget complains because of that. To fix the issue create a fullchain.pem file composed of both the chain.pem and the cert.pem files, e.g.,
cat cert.pem chain.pem > fullchain.pem
Then use the fullchain.pem with the PemTrustOptions configuration.
You don't need to put the LE root certificate in the fullchain.pem file, because it should already be present on both client and server side. Here's an excerpt from the TLS Protocol RFC about it.
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
I have a backend server with SSL only as defaut public interface. This server listens on 443 with cert, key and ca files on, ssl verify client is set to true.
On client side, I have client cert, key and a ca file made of 2 CA files catted together (intermediate CA, root CA) in a single ca.pem file. When I do curl request on my backend server, it works fine. I also tested the server / client cert and key with gnutls-serv and openssl s_server to ensure all was valid.
But when I create a keystore on Apigee (client cert and key file [pem format]) and a trustore (ca.pem file), there is an error:
- target.name fsbca-test
- Properties
- Expression ("fsbca-test" equals target.name)
- ExpressionResult true
- Tree TARGET_fsbca-test
- error The Service is temporarily unavailable
- error.cause General SSLEngine problem
- error.cause.cause General SSLEngine problem
- error.class com.apigee.messaging.adaptors.http.HttpAdaptorException
- state TARGET_REQ_FLOW
- type ErrorPoint
If I put SSL verify client to false on my backend, then the request is correctly diverted by Apigee and I get the response.
If I put IgnoreValidationErrors to true in the target endpoints property, then the request is diverted to my backend server but I can see an error in the server's log: "client sent no required SSL certificate while reading c...".
Any ideas about what could be wrong in what I am doing?
Additional track: could it be an issue on Apigee side with the CA file made of 2 certs (it may ignore trailing certificates found in a .pem). If wanted to test pkcs12 and jks but I failed to upload them to Apigee (the API doc page only describes .pem, JAR and cert action). I wrote a small Java client with pkcs12 keystore and jks trustore and it worked fine from my local workstation.
Thank you in advance for any piece of information that could help me.
Regards
Fr
You should upload your certificates separately (one per cert), and you need the entire trust chain of certificates to be stored in your truststore.
Here is the page about SSL to your backend.
EDIT:
Here is a method I know works:
1) Separate certs into separate PEM files. Do not put more than once cert in a file.
2) Validate each cert using openssl:
openssl x509 -noout -text -in <cert file name>
Validate that no certs are expired, and that the Subject and Issuer fields create a chain of all the certs, with identical names.
The server's certificate, the root certificate, and all certificates in between need to be in the truststore.
Now i have a X509 leaf certificate. From the certification path to see, there's a intermediate cert and a root cert in it.
I want to generate the intermediate cert(..CA- G3) and the root cert(VerSign). Currently, my way is to double click the intermediate one and then click "Copy to file.." to export it. Do same for the root one too. Is this way to correct to generate intermediate/root certs?
From my test result, it seems the generated root cert with wrong fingerprint. The fingerpring doesn't match the one on server side.
Anyone can help on how to generate intermediate/root certs correctly?
You have fundamental misunderstanding of certificates and certificate chains.
CA and Root certificates are searched for and found, not generated.
Some certificates include location of their CA certificate in the body of the certificate (in special certificate extension). For others you need to look in your CA certificates storage (this is what Windows does). Sometimes chains are sent together with end-entity certificate (depending on data format). Finally, sometimes CA and Root are just not available.
[supply the answer... , maybe this is an alternative approach to get all certs that the SSL server using]
To retrieve the ntermediate and root certs by OpenSSL command:
openssl s_client -showcerts -connect [host]:[port]
I am trying to verify an SSL connection to Experian in Ubuntu 10.10 with OpenSSL client.
openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443
The problem is that the connection closes with a Verify return code: 21 (unable to verify the first certificate).
I've checked the certificate list, and the Certificate used to sign Experian (VeriSign Class 3 Secure Server CA - G3) is included in the list.
/etc/ssl/certs/ca-certificates.crt
Yet I don't know why it is not able to verify the first certificate.
The entire response could be seen here:
https://gist.github.com/1248790
The first error message is telling you more about the problem:
verify error:num=20:unable to get local issuer certificate
The issuing certificate authority of the end entity server certificate is
VeriSign Class 3 Secure Server CA - G3
Look closely in your CA file - you will not find this certificate since it is an intermediary CA - what you found was a similar-named G3 Public Primary CA of VeriSign.
But why does the other connection succeed, but this one doesn't? The problem is a misconfiguration of the servers (see for yourself using the -debug option). The "good" server sends the entire certificate chain during the handshake, therefore providing you with the necessary intermediate certificates.
But the server that is failing sends you only the end entity certificate, and OpenSSL is not capable of downloading the missing intermediate certificate "on the fly" (which would be possible by interpreting the Authority Information Access extension). Therefore your attempt fails using s_client but it would succeed nevertheless if you browse to the same URL using e.g. FireFox (which does support the "certificate discovery" feature).
Your options to solve the problem are either fixing this on the server side by making the server send the entire chain, too, or by passing the missing intermediate certificate to OpenSSL as a client-side parameter.
Adding additional information to emboss's answer.
To put it simply, there is an incorrect cert in your certificate chain.
For example, your certificate authority will have most likely given you 3 files.
your_domain_name.crt
DigiCertCA.crt # (Or whatever the name of your certificate authority is)
TrustedRoot.crt
You most likely combined all of these files into one bundle.
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: DigiCertCA.crt)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: TrustedRoot.crt)
-----END CERTIFICATE-----
If you create the bundle, but use an old, or an incorrect version of your Intermediate Cert (DigiCertCA.crt in my example), you will get the exact symptoms you are describing.
SSL connections appear to work from browser
SSL connections fail from other clients
Curl fails with error: "curl: (60) SSL certificate : unable to get local issuer certificate"
openssl s_client -connect gives error "verify error:num=20:unable to get local issuer certificate"
Redownload all certs from your certificate authority and make a fresh bundle.
I came across the same issue installing my signed certificate on an Amazon Elastic Load Balancer instance.
All seemed find via a browser (Chrome) but accessing the site via my java client produced the exception javax.net.ssl.SSLPeerUnverifiedException
What I had not done was provide a "certificate chain" file when installing my certificate on my ELB instance (see https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate)
We were only sent our signed public key from the signing authority so I had to create my own certificate chain file. Using my browser's certificate viewer panel I exported each certificate in the signing chain. (The order of the certificate chain in important, see https://forums.aws.amazon.com/message.jspa?messageID=222086)
Here is what you can do:-
Exim SSL certificates
By default, the /etc/exim.conf will use the cert/key files:
/etc/exim.cert
/etc/exim.key
so if you're wondering where to set your files, that's where.
They're controlled by the exim.conf's options:
tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key
Intermediate Certificates
If you have a CA Root certificate (ca bundle, chain, etc.) you'll add the contents of your CA into the exim.cert, after your actual certificate.
Probably a good idea to make sure you have a copy of everything elsewhere in case you make an error.
Dovecot and ProFtpd should also read it correctly, so dovecot no longer needs the ssl_ca option.
So for both cases, there is no need to make any changes to either the exim.conf or dovecot.conf(/etc/dovecot/conf/ssl.conf)
If you are using MacOS use:
sudo cp /usr/local/etc/openssl/cert.pem /etc/ssl/certs
after this Trust anchor not found error disappears
For those using zerossl.com certificates, drag and drop all certificates (as is) to their respective folders.
Cut and pasting text into existing files, may cause utf8 issues - depending upon OS, format and character spacings.