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.
Related
I can't connect with my Tableau Server from Tableau Desktop because it shows me that error: SSL certificate is not valid. I'm searching for a solution, but I'm only reading how to change the certificate with another, beacause I do not have any other certificate.
My question goes before that: how can I get a certificate? where I can get it from?
This is the guide from Tableau I use whenever I need to setup SSL for my servers. It includes obtaining an SSL Certificate from a certificate authority Steps for SSL Cert
To configure Tableau Server to use SSL, you must have an SSL certificate. To obtain the SSL certificate, complete the steps:
Set the OpenSSL configuration environment variable (optional)
Generate a key file
Create a Certificate Signing Request (CSR)
Send the CSR to a certificate authority (CA) to obtain an SSL certificate
Use the key and certificate to configure Tableau Server to use SSL
I can connect fine with Python to any external https site without this error:
SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108)')))
But I have a local webserver on my laptop with a self-signed certificate that works fine in itself but Python generates an _ssl.c:1108 error when I try to connect to it.
Any ideas?
The python client does not have access and trust the CA certificate that signed the web server certificate. In your case that is the self-signed web server certificate.
To get the python client working, you can do the following:
disable certificate verification. That is not a good idea but I guess is ok for a quick test. The emphasis is on "it is not recommended".
Download the self-signed certificate and make it accessible to the python client and specify it as trusted CA certificate.
Download and install a certificate from well known CAs such as LetsEncrypt (free) or commercial CAs. This is the recommended approach.
You could go into depth on the items mentioned herein and get a conceptual understanding how TLS operates.
EDIT 1: You could also get a free certificate from LetsEncrypt CA. Or you could get a free test certificate from most of the commercial CAs like DigiCert etc. See this link for getting and installing a free test certificate signed by a DigiCert test CA.
See this for details on python client configuration for TLS.
I have multiple Intel NUCs out in the field that I use for displaying digital signage. Out of the thousands I have in the field, a couple complain with this error:
SSL certificate problem: self signed certificate in certificate chain. More details here: http://curl.haxx.se/docs/sslcerts.html, curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
I've confirmed that the cert is not expired, and the domain name matches
These units are running on Debian 7
Could the network they are on cause this issue with some sort of firewall setting?
When you visit the website what certificate is shown in the web browser? In your curl bundle is that the same certificate which is supposed to be used for SSL encryption? I'd guess no. CA will sign your cert.pem so that web browsers will show your green lock thereby authenticating your website. You most likely have an issue on the back end with the configuration of your curl bundle. You need to make sure that your server is using the CA cert not a self signed certificate like ssl-cert-snakeoil.pem for example.
Essentially your website should be using a static IPv4 address. As far as a network firewall stopping an SSL handshake from happening that may be possible, I have seen it happen on specific ports for example port 22 for ssh connections may be blocked at the network gateway for inbound traffic on a client side computer attempting a connection to a server. The SYN/ACK https://tools.ietf.org/rfc/rfc793.txt TCP handshake may time out in that type of network fire wall situation. However since you are getting an explicit response from your server about a self signed cert a firewall issue does not seem to be the problem.
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?
So far, I've used openssl, sslyze, keystore utilities, and some of the standard Windows diagnostics commands to try and characterize this problem. The summary is that as soon as I attempt to use a keystore that has the CA signed certificate in it, I get an immediate handshake failure 40 after the client hello. The connection never gets as far as a server hello with the CA cert in place.
On the same machine (Windows Server 2012), if I use a self signed certificate, the connection works as expected.
Openssl shows the handshake failure with the CA certificate in place.
sslyze shows all ciphers rejected with either no ciphers available or TLS / Alert handshake failure.
The fact that this is successful with a self-signed certificate tends to indicate that the "basics" are there, that the client and server have the necessary ciphers and so on to connect, and that server.xml is configured properly.
There were no error messages when importing the certificates, and everything seems to be configured correctly with the CA certs based on keytool checks. There are no error messages given during server start to indicate any problems processing the certificate.
Is there something I should be looking more closely at in regards to the keystore with the CA cert that could cause this complete rejection of the client hello? How would a different keystore or CA certs within aaffect the earliest steps of the handshake?
Thank you for information provided.
I assume that you are talking about a server side certificate and a server side key store, since the error happens at a state where no client certificates are yet involved. If the server is able to send the self-signed certificate to the client, but is not able to send the CA signed certificate to the client, then it must be something wrong with the certificate you are trying to send or that the certificate can not be used together with the ciphers offered by the client.
Since the problem is obviously on the server side you should first check all logs written on the server side for hints what the error might be. Typical problems are non-existing files, wrong files, password protected client key w/o providing a password or that the key does not belong to the certificate.