We're updating the wild card cert in all our servers this month, including three nginx proxy servers. Two of those worked right away, the third gets this error:
nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/pki/tls/private/domain.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
The same cert works for the web interface and webmin.
Tried creating a self-signed cert to test and got the same error.
All three servers are on Centos 7 and nginx 1.16.1.
We're using the PEM file with the cert and intermediate cert, but also tried with just the cert.
Other suggestions?
Related
We have 2 environment one for test purpose and one for development both have the cluster configuration.
But on test environment we are facing some Vulnerabilities due to SSL certificate.
On Neo4j cluster environment facing some Qualys Vulnerability issue :
SSL/TLS Server supports TLSv1.0
SSL Certificate - Invalid Maximum Validity Date Detected
SSL Certificate - Self-Signed Certificate
SSL Certificate - Subject Common Name Does Not Match Server FQDN
SSL Certificate - Signature Verification Failed Vulnerability
To me it looks like Qualys is just letting you know about some issues with the SSL certificate:
-It's out of date
-It's Self Signed (Not issued by a Trusted Certificate Authority)
-In some configuration there's a common name which is mismatched to the domain name for server Look here: https://discussions.qualys.com/thread/19643-ssl-certificate-subject-common-name-does-not-match-server-fqdn#comment-46647
Look here for last one: https://discussions.qualys.com/thread/17873-qid-38173-ssl-certificate-signature-verification-failed-vulnerability
It looks to me like your options would be to either change your settings in Qualys per that last link and reissue SSL Certificate to resolve issues, or get SSL Certificate issued by a trusted CA.
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'm using an autosign script in Puppet to sign certificates. This is actually working, but I'm experimenting a problem when a machine try to request again a certificate (eg. ssl directory is removed). In this cases, a cached certificate is used and obviously does not match with the certificate created by the agent. Here is an example output:
Info: Creating a new SSL key for foo.bar.com
Info: Caching certificate for ca
Info: Caching certificate for foo.bar.com
Error: Could not request certificate: The certificate retrieved from the master does not match the agent's private key.
Certificate fingerprint: 41:B7:ED:3C:EC:A9:EF:A9:51:8C:6C:46:94:B1:30:09:72:2F:CC:D2:13:BA:A5:63:A7:2D:C5:FB:BD:DF:A5:B4
I don't want/can't remove certificates by hand executing puppet cert clean so I tried to use allow_duplicate_certs but seems to be buggy since... quite a lot time.
Do you know any other option to re-autosign a certificate when the host already have a signed certificate in the CA?
I've got to put 2-way ssl on some laptops where each one has its own different cert. On the server, I've got to configure IIS7 to trust all client certs from the issuer, so that the different certs are all accepted. I've set my IIS7 site to 'require ssl' - 'require client certificates'. I've got the one-way SSL on the domain already configured to use a cert I obtained from GoDaddy, and that's working well. When I try to make it work with 2-way ssl, I can't get it working.
The issuer in question is the company themselves, so they issue their own certs.
So far I've been given the following by my client:
Root .cer for issuing company
Chained .p7b file that contains the ROOT, SUBONE and Test.cer Client
Test.cer that came from a CSR I generated on my development machine issued by SUBONE
My question is - Where do I put everything, and what settings do I need to configure this so it works?
(client: Win7, server: 2008Server, IIS7 - all bang up to date)
I'm trying to install a Comodo SSL certificate on a shared server, which has directadmin installed. I have assigned the user an unique ip address, made the CSR request and uploaded the certificate.
In directadmin I get the response that both the certificate and private key are saved. Unfortunately, when I browse to the https://www.domain.com I get a SSL error, saying that the certificate is untrusted, because it is self-signed.
I'm confused why this error occurs. It seems to me that I followed the correct steps to install the Comodo ssl certificate. I also tried deleting the private key and certificate through the command line on the server. But this does not seem to resolve the error.
What direction should I be looking into solving this issue?
Check if you installed the intermediate certificate. You have to list one or more intermediate certificates in the field for your public key.
You can also use the GlobalSign OneClickSSL plugin for DirectAdmin and let the plugin do everything for you automatically.
See: https://www.globalsign.com/ssl/oneclickssl/directadmin/
And: http://www.youtube.com/#/watch?v=tVP9i6Ing1M