I have the following in my configuration file:
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/intermediate_ca;
My certificate is issuing unsecure warnings to the browser and I think it might just be because I am missing the file that presents the intermediate chain to the server. Even so, I'm using comodo positivessl and can't find this file after searching for it endlessly on ssls.com and google. Does anyone have any idea on how I should go with this? A cipherscan in my server issues "Certificate: untrusted" and "OCSP stapling: not supported" although I have ssl_stapling on; ssl_stapling_verify on; on the file.
You can download the Comodo intermediate certificates from this page. Depending on when your certificate was issued, you should download either the SHA2 or SHA1.
Be sure to scroll the list and download the files associated with the PositiveSSL row in the table.
Once downloaded, combine all the files in a single .pem file:
- the server certificate (then one you received)
- the intermediates, from the most specific to the most generic
Store the file on the server and configure Nginx properly using the following settings:
ssl on;
ssl_certificate /path/to/bundle.pem;
ssl_certificate_key /path/to/private-key.key;
Related
I have created my own ca certificates with openssl. I have four files :
ca.key (private ca key)
ca.crt (public ca certificate)
server.key (private key)
server.crt (public certificate signed by the ca files)
I use nginx with ssl configuration.
ssl_certificate server.crt;
ssl_certificate_key server.key;
If I install the ca public certificate on my computer, my browser let me go on the website without adding exception which is good. But if I have not the ca certificate installed on my computer, I have to add exception to pass. I want to avoid adding exception and force user to have the ca certificate installed on their computer.
I configure nginx with hsts (http strict transport security) :
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca.crt;
Unfortunately I have again the possibility to add an exception to pass.
I'm wondering if it is possible to do this ?
I realize that my certificates doesn't work with chrome missing_subjectAltName. So I fixed it with this link. And now I have this message with chrome if my ca certificate is not installed on my computer :
You cannot visit localhost right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
This is exactly what I want. However it doesn't work on firefox et let me the possibility to add an exception.
Why chrome block it and not firefox ? How can I do that on firefox too ?
I've configured an NGINX reverse-proxy with SSL certificate and it works fine in Chrome and IE, but give me an SSL error (SEC_ERROR_UNKNOWN_ISSUER) in Firefox.
Why is that?
I've just found another answer to a similar problem that explains that this happens if the certificate chain is not fully sent by the server (or in this case the load balancer).
This other answer explains that Chrome looks for this missing chain certificates by itself while Firefox does not. Actually Firefox caches intermediate certificates from earlier connections to other sites, but in my case since I'm mostly using Chrome, Firefox didn't had any cache of these Sectigo (Comodo) root certificates, that's why I was getting the validation error.
When I purchased my PositiveSSL certificate I've received both the "crt" file for my domain but also a "ca-bundle" file which is the certification authority bundle. Both these files should be concatenated (first my certificate, followed by the certificates for the authority chain), and this combined file is what should be configured as ssl_certificate in NGINX.
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 am using Nginx to create a secure connection; when I revoked the client certificate, I also can connect to Nginx by https, I know I should config the ssl_crl directives, but I want to use OCSP to verify the client certificate, How should I do? I found Nginx use OpenSSL library to establish ssl connection, Is there something I should do with openssl.cnf file?
Client certificate validation with OCSP feature has been added to nginx 1.19.0+.
For example:
ssl_verify_client on;
ssl_ocsp on;
resolver 192.0.2.1;
ssl_ocsp enables OCSP validation of the client certificate chain.
ssl_ocsp leaf; enables validation of the client certificate only. By default ssl_ocsp is set to off.
ssl_verify_client directive should be set to on or optional for the OCSP validation to work
resolver should be specified to resolve the OCSP responder hostname.
Update
Nginx added support for client certificate validation with OCSP in version 1.19.0, released 26 May 2020. See ssl_ocsp and related directives.
Original answer
Nginx does not support OCSP validation of client certificates. The only option of validating client certificates is to use CRLs, update them and reload Nginx to apply the changes.
In this thread one of the leading Nginx developers confirms that and says that nobody is working on it as of 2014:
https://forum.nginx.org/read.php?2,238506,245962
Prerequirements:
running pki with OCSP configured
NginX Server config
# Specifies a file with trusted CA certificates in the PEM format used to verify client certificates and OCSP responses if ssl_stapling is enabled.
# The list of certificates will be sent to clients. If this is not desired, the ssl_trusted_certificate directive can be used.
ssl_client_certificate /etc/nginx/client_certs/ca.crt;
ssl_verify_client on;
ssl_stapling on; #Yes this has to be configured to use OCSP
resolver 192.0.2.1;
information on ssl_verify_client
informations on ssl_client_certificate
This is just a sample of how the code should look like in your server block:
server {
# Listen on port 443
listen 443 default_server;
server_name example.com;
root /path/to/site-content/;
index index.html index.htm;
# Turn on SSL; Specify certificate & keys
ssl on;
ssl_certificate /etc/nginx/ssl/example.com/my_certificate.crt;
ssl_certificate_key /etc/nginx/ssl/example.com/example.key;
# Enable OCSP Stapling, point to certificate chain
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/full_chain.pem;
}
make sure the certificates match your paths, and then Save your work.
Test your configuration before reloading...
and last, restart or reload Nginx by either of the following commands:
sudo service nginx reload
or
sudo service nginx restart
Final step, test your OCSP Stapling through this link to make sure your SSL is working or not:
OCSP Stapling SSL Checker
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.