I'm trying to set up Drone using TLS but the drone agent can't connect to the server with the error:
connection failed, retry in 15s. websocket. Dial wss://drone-server:8000/ws/broker: x509: certificate signed by unknown authority
I've generated the necessary files and my docker-compose file for the drone server has DRONE_SERVER_CERT and DRONE_SERVER_KEY values set with the certificates, so I think the only problem is that it's self-signed. But I'm not sure how to set up the certificates with the drone image to have it recognize the certificate's CA. Is there a way to set that up or am I going about this in completely the wrong way?
As far as I understand the drone CLI client, uses the systems' trusted certificate storage as most* applications do. So for your client to start trusting the server's self signed certificate, you should add the CA cert to your system storage.
A good guide on how to install a CA cert can be found in this answer.
*browsers usually have their own CA cert DB
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.
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.
When generating a self-signed certificate using keytool, can I use an IP address for the Common Name?
Once I generated the certificate, I exported it so I can install it in my clients/browsers. In Windows, I ran mmc.exe and added it as a Trusted Root Certificate Authority.
However, when I navigate to the IP address in my browser, it is still an untrusted connection. I ensured Tomcat had all the correct Connector settings.
Am I doing this correctly? do I need to be my own CA? How can I use SSL for development purposes? I'm still trying to understand SSL completely.
First question: if you'll be connecting by IP, then yes.
Second question: No, you don't install your self-signed certificate as CA, you just add exception when your browser warns you that it's self-signed.
You can set up CA — you generate root certificate first, install it in the client, and then generate CSR and then server certificate from it (see e.g. this), but for development purposes this is a complete waste of time.