I can't figure out how to get Trusted TLS connections between my primary mail server (mail.sfnet.it) and mail exchanger (mx.sfnet.it)
They both use Postfix as MTA and they both have a PositiveSSL certificate installed and everything seems to work well, except for trusted handshake.
I've set CA path, reconfigured package, but nothing to do. Any idea?
Postfix log says:
postfix/smtp[20689]: Untrusted TLS connection established to mail.sfnet.it[94.23.65.191]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
It may be necessarily to specify a path to trusted certificates with smtp_tls_CApath:
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_CApath = /etc/ssl/certs
Can you check if the certificate is correctly installed for mail.sfnet.it on the smtp port? SSL Labs (https://www.ssllabs.com/ssltest/analyze.html?d=mail.sfnet.it&hideResults=on) indicates that the server's certificate is untrusted (self-signed) on 443 and I suspect it may be the same on the smtp port as well.
The connection is untrusted because the sender MTA doesn't recognize the CA that signed the recipient MTA's certificate. To make the MTAs trust each other's certificates, you have to install the CA certificate on both the MTAs. The installation process depends on what distro you are using. Here is an example for centOS.
You can get the CA certificate from the official positivessl site. Here is what I found.
Related
I am working on the Microchip WINC3400.
I can establish a TLS socket connection.
For testing purpose i would like to disable root CA certificate verification.
Is this possible on WINC3400 and if so, how can I do this?
Recently I was debugging a mutual TLS issue between a MQTT client and a broker.
For the TLS setup, a self-signed CA was used to sign both server certificates and client certificates.
Both server and client trust stores had the CA certificate present.
During the handshake I observed, both brokers (RabbitMQ and Mosquitto) sent the CA certificate along with the server certificate.
But on clients, except for JAVA(PAHO), the Python and the nodejs clients both were also sending the CA certificate they had with their response to the server.
If the CA certificates were already installed in the trust stores of both the server and client, why should they exchange the CA at all during the handshake?
PS: Also JAVA client was never sending the CA certificate in its response. In which case, if the server did not send the certificate the handshake failed, but for other clients even if the server did not send the CA in the handshake, the clients were sending the CA in their response and the handshakes were successful.
In general the root CA certificate don't need to be sent inside the TLS handshake, no matter if for client or server certificate. Trust anchors (i.e. the root certificate as the base of the trust chain) need to be already trusted by the peer and thus cannot be taken from a still untrusted network connection. If root CA is sent anyway it will be simply ignored.
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
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.
I'm trying to set up client certificate authentication. I was able to generate a CA-, server- and client-certificate. As long as I use Fiddler everything works as expected. However, as soon as I start using a browser it doesn't work anymore (HTTP Error 403.7 - Forbidden).
Of course I imported the client certificate in the Personal store and I made sure Client Certificate Negotiation is enabled.
I also tried openssl s_client -connect 127.0.0.1:443 -state -debug but I couldn't really make sense of the result... The only thing what's weird is that my CA doesn't show up in the Acceptable client certificate CA names section.
Anything else I could try?
Update:
I think it doesn't matter but my server certificate is set up for 127.0.0.1. Therefore I'm using https://127.0.0.1/... in my browsers.
Update2:
Using Wireshark I noticed that my servers' response depends on the client:
Fiddler (OK):
Client Hello
Server Hello, Certificate, Server Hello Done
Browser (Not OK):
Client Hello
Server Hello, Change Cipher Spec, Encrypted Handshake Message
Update3:
After enabling clientcertnegotiation the server response is different but still doesn't work:
Server Hello, Certificate
Certificate Request
Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
My self-signed CA doesn't seem to be in the Distinguished Names list...
Update4:
SSL Settings: Checked Require SSL and Client certificates set as Required. Client cert shows up in Personal and the intended purpose is Client Authentication.
I finally found the issue and a workaround:
As mentioned in Update3, Distinguished Names doesn't contain my CA. This is because Distinguished Names has a limit of 2^14 bytes (16384 bytes). Because I do have a lot of CA installed on my machine my CA simply didn't make it in. The TLS standard would allow to send multiple messages but unfortunately Windows doesn't support this!
As mentioned here you have a few possibilities. The simplest one is this:
At your server add a DWORD (not QWORD!) value called SendTrustedIssuerList in your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and set it to 0. This will prevent your server from sending a list at all, letting the client choose from any installed client certificate.
Unfortunately I couldn't see any traces in the Event Viewer (as reported elsewhere). Therefore the issue wasn't easy to spot (I had to use Wireshark in order to check Distinguished Names).
Use the Accept option instead of the Require option of the "Client certificates" feature.
In IIS Manager, locate the Web application for which you want to change the SSL setting.
In Features View, double-click SSL Settings.
On the SSL Settings page, select the Accept option under Client certificates.
In the Actions pane, click Apply.
More info here
Client certificate should be imported in CurrentUser\My store with private key (i.e. p12 or pfx file usually).
CA certificate should be in LocalMachine\Root store so that IIS trusts all certificates issued by the CA and the CA is trusted for every user on the computer.
CRL issued by the CA should be either available through URL (specified in every end entity certificate that CA issued) or imported in LocalMachine\My store.
NOTE: openssl doesn't use windows certificate store so this will have no efect on openssl s_client -connect 127.0.0.1:443 -state