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 have Create SSL certificate using "Let's Encrypt" in Ubantu 18.10 .i follow below documentation to create SSL certificate.
https://www.linode.com/docs/security/ssl/install-lets-encrypt-to-create-ssl-certificates/
I have check SSL certificate was successfully created I have used below command to test it.
openssl verify chain.pem
openssl verify -CAfile chain.pem cert.pem
But Site not working getting 525 error.In cloudflare ""Universal SSL is Active "
Anyone please suggest possible solution to fix this Issue?
Thanks
I found solution. there is issue with apache config file.I have change port "443"
in apache config file and its working fine.
Thanks
I'm trying to get HTTPS work on all subdomains using"Nginx", but receive:
This server could not prove that it is api.wokcraft.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
URL: https://api.wokcraft.com/
Can any one inform what missing?
thx
edit: I followed this instructions: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/1091/0/certificate-installation--nginx
Nginx doesn't send the correct list of intermediate certificates: https://www.ssllabs.com/ssltest/analyze.html?d=api.wokcraft.com&latest
Create the correct bundle:
You want to create Comodo Bundle this way (replacing your_cert with actual name of your file):
cat your_cert.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > your_cert.ca-bundle
Get the new ca-bundle onto your server
Once that is done copy this to your server as in the Nginx set it this way:
ssl_certificate /your/ssl/path/your_cert.ca-bundle;
ssl_certificate_key /your/ssl/path/your_cert_privateKey.key;
Verify the cert and key are matching after they have been copied (compare md5 hashes).
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
Test the config (need to run as sudo):
sudo nginx -t
If no errors, reload nginx and re-run you SSLlabs check:
https://www.ssllabs.com/ssltest/analyze.html?d=api.wokcraft.com
I've gotten SSL to work on Apache servers and on a client's Nginx server. However, I am having issues with my EV SSL certificate installation. This is also on a server with a special character in the URL: weöm.com.
weöm.com is displayed as xn--wem-tna.com in browsers, which is fine. When I inspected my .ca-bundle that was emailed to me from COMODO, I saw my domain name rendered as we\xC3\xB6m.com, which made me think I have to generate my .csr and .key the same way.
Here's how I've been doing it (ran this command in Terminal):
openssl req -new -newkey rsa:2048 -nodes -out weom.csr -keyout weom.key -subj "/serialNumber=000000000/businessCategory=Private Organization/C=US/postalCode=00000/ST=California/L=Cupertino/street=1 Loop Way/O=Apple Inc/OU=COMODO EV SSL/CN=we\xC3\xB6m.com"
(I've replaced the serial number and other things with fake data in my example)
The code spits out a .csr and .key with the exact same data that my compiled .crt has and I cannot understand why I'm still getting this SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch error.
I've been wrangling with this for about a week, does anyone have any idea what I'm doing wrong?
EDIT: Proving more information...
Here is how I'm creating my master .crt:
cat xn--wem-tna.com.crt AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSAExtendedValidationSecureServerCA.crt >> cert_chain.crt
This is the default file in my sites-available folder:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name xn--wem-tna.com;
return 301 https://$host$request_uri;
}
server {
# SSL configuration
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate cert_chain.crt;
ssl_certificate_key weom.key;
ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name xn--wem-tna.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
The reason for the error is that your KEY and CRT are different.
You can verify this by checking MD5 hashes on them:
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
Additionally I would change the order in the bundle CRT (cert_chain.crt),at the moment you have it this way:
xn--wem-tna.com.crt AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSAExtendedValidationSecureServerCA.crt
It should be:
cat xn--wem-tna.com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > cert_chain.crt
This is Official Comodos Certificate Installation: NGINX
What gets me worried is your comment at the beginning:
If you have changed the key once your certificate had been issued you will need to invalidate it and apply for a new CRT with your new KEY and new CSR.
weöm.com is displayed as xn--wem-tna.com in browsers, which is fine. When I inspected my .ca-bundle that was emailed to me from COMODO, I saw my domain name rendered as we\xC3\xB6m.com, which made me think I have to generate my .csr and .key the same way.
Oh yeah, forgot to update.
I got a refund and went with CertSimple. Emailed them questions Friday night, went through the entire process of obtaining an EV cert Saturday morning/afternoon, and had it on my server by 6pm (and that's only because I was out running errands).
So I've been sent a new public cert to install on a server (.crt file). Done. Restart apache - "FAILED".
Error message:
[Tue Jan 11 12:51:37 2011] [error] Unable to configure RSA server private key
[Tue Jan 11 12:51:37 2011] [error] SSL Library Error: 185073780 error:0B080074:
x509 certificate routines:X509_check_private_key:key values mismatch
I've checked the key values:
openssl rsa -noout -modulus -in server.key | openssl md5
openssl x509 -noout -modulus -in server.crt | openssl md5
and they DO match.
I've checked the paths in my ssl.conf file, and they ARE pointing to the correct files.
If I reinstate the old (expired) cert file, apache starts up ok, so it definitely doesn't like something about the new one.
It's a GeoTrust QuickSSL, and it came with an "intermediate.crt" that I'm supposed to use in place of the the "ca-bundle.crt" file that I was using before
SSLCertificateFile /etc/pki/tls/certs/www.domain.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.domain.com.key
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
Any ideas what I might be doing wrong? Any more info you need?
Thanks!
I also came across the same error. In my case I had to supply additional CA certificates in the verification chain. And instead of supplying the certificate and the key in separate files, I combined them in a .pem file.
However, when you do this, the order of the key and the certificate plus the intermediate one(s) is important. The correct order:
your private key
your certificate
(intermediate) CA certificate lowest in the hierarchy
other CA certificates higher in the hierarchy...
(intermediate) CA certificate highest in the hierarchy
I had the same issue on one of my CentOS 6.5 servers recently and it was down to when I generated the KEY and CSR.
I have three sites running on this server in virtualhosts all with dedicated IPs and each site has its own SSL Certificate.
In a rush, when changing one of the certificates, I stupidly just followed the certificate provider's guide to gaining the CSR and installing it in Apache, and I was instructed to use the following command:
openssl req -new -newkey rsa:2048 -nodes -keyout domain-name-here.key -out domain-name-here.csr
After installing the new certificate I was then also facing Apache not starting and the same errors in /var/log/httpd/ssl_error_log:
[error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
[error] Unable to configure RSA server private key
Now what I really should have done was check my .bash_history files, as I have successfully done this in CentOS many times before.
I should have run these two commands instead :
openssl genrsa -des3 -out domain-name-here.co.uk.key 2048
openssl req -new -key domain-name-here.co.uk.key -out domain-name-here.co.uk.csr
This then successfully generated the CSR and KEY, and I re-applied for the certificate using the newly gained CSR, then applied the new certificate and added the new key file and finally then Apache would start cleanly.
Also, just to note, after a little configuration we now score A+ in an SSL labs test.
When reissuing my Rapid SSL certificate (purchased through Namecheap) to deal with the Heartbeat bug, the new certificate was always issued against the private key used for the previous CSR request. After about the fifth reissue, pairing that with the private key used in the fourth reissue attempt made things work fine.
make sure all cert files are encoded using ANSI, not UTF-8.
For me all tests said: key, crt and csr do match, but the logs said X509_check_private_key:key values mismatch until I saw that one of the files was encoded in UTF-8.
In my case, I had two sites and two subtley different private keys:
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/some/path/server.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
After I fixed that, the error message changed to mention /some/path/server.pem. Note the different private key, which only differed in file extension. I had 2 different sites encrypted with different keys (meaning I had fixed the first site but now needed to fix the second site). So be sure to read the error message carefully!
We also had the issue with NameCheap, the issued Cert matched the CSR that was used to generate the previous CERT. We let them know via their support page, and they said they already knew about the issue.
According the FAQ on the Apache website, the modulus and the public exponent for the cert and the key must match so that is a valid check.
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#verify
As you and others have already stated, work with the cert issuer
The trickiest bit in my case is setting up the SSLCACertificateFile. Once the certificate company issued our cert, alongside it we received two additional certs: an intermediate and a root certificate. Which one to use for SSLCACertificateFile? Both..
Here's what my certificate chain look like:
And for the SSLCACertificateFile I have to concatenate digicert_sha2_high_assurance_server_ca.crt and digicert.crt into one file in the mentioned order.
Dynadot seem to have the same issues with the RapidSSL certificates they are re-issuing. I just received a non working certificate, which then triggered another issue with Apache, when that was fixed I found this question and answer here for the original problem, thanks for the information everybody. I shall be scrapping the RapidSSL Cert as I have some client compatibility issues with it anyway and purchasing a new one from AlphaSSL instead.