Using OpenSSL 1.1.1n. The server uses LetsEncrypt certificates. How do I find the best cipher? OpenSSL says "openssl ciphers -tls1_2 -s" will provide a short list of the best ciphers but I haven't been able to match one of them up with the LetsEncrypt certificate(s)?
There is no need to match up ciphers with your cert. Unless you have a strong reason to do otherwise, the simplest and likely best course of action is to follow the Mozilla configuration generator:
9 Likes
Unfortunately this isn't browser related. It is for very simple tls use and I don't own the server or know anything about it except that it uses LetsEncrypt certificates. I'm pretty sure my final config is similar to NGenix but that is a rough guess. My device does not have NGenix.
You could try checking the site with SSL Labs. It reports on some config options for servers including ciphers. As danb noted, the cert is not related to the server owner's choice of ciphers.
6 Likes
The SSLLabs tool gave me an answer for one of 2 servers but reports the other server may be behind a firewall and can not be reached for for tests. 
To be exact, there is a very minor relationship between TLS cipher suites and certificates in TLS v1.2 and below (removed in TLS v1.3):
ECDHE-**RSA**-AES128-GCM-SHA256
ECDHE-**ECDSA**-AES128-GCM-SHA256
these two cipher suites are identicial except for their signature algorithm. Because the certificate is involved in the signature, the first cipher suite can only be used for RSA certificates. Similarly, the second can only be used with ECDSA certificates. Similar things also apply to static RSA key exchanges, but we wouldn't recommend them anyway (you will typically find them labeled as "weak" or even "insecure" in various TLS scanners or configuration guides).
In practice, you're just going to configure both cipher suites in whatever configuration you have. All typical TLS implementations ignore cipher suites not applicable - they figure this out by themselves, so you don't have to care about this.
The configuration generator linked by @danb35 is actually based on a wiki article from Mozilla. If you can't use the generator for whatever reason, you can still find a list of recommended cipher suites in the mozilla article. We typically recommend the "Intermediate configuration", which lists a recommended, secure and mostly compatible configuration.
If you do not have access to the server at all, you probably cannot configure cipher suites on it. If that's the case, you have to use the cipher suite configuration choosen by whoever has access.
8 Likes
Hmmm... Good info. I think we're mixing nomenclature. I'm defining the cipher on the client (me). I keep getting "bad handshake - failed". I'll try the 2 ciphers you mention.
3 Likes
On a client, you typically want to not restrict the cipher suite configuration: The client makes an offer, and the server chooses one of the offered cipher suites. So if you're configuring a client, in most cases you don't want to configure anything at all: Your default TLS implementation should allow a wide range by default. which you should keep.
There are a few scenarios where restricting the client cipher suites is sensible for security reasons, but if you are trying to keep compatibility with various (unknown) servers, restricting them is usually not the way to go.
6 Likes
Hello @hraycrum69,
If I remember correctly your application for Certificates was for VoIP with SIP protocol,
which may not fit the typical scenarios (not saying in the least you have an invalid scenario).
If you are working with SIP the SIP servers and clients may have recommendations of their own that would likely best to follow, as that is what they expect and the streaming nature of VoIP there maybe a "best cipher" that is not the same as a "best cipher" for HTTPS.
Am not an expert, just bringing up somethings to think about.
--
@Bruce5051
4 Likes
If the system responds to secure connections, you could find all the supported ciphers via walking through the connection list.
Try ALL ciphers:
openssl s_client -connect google.com:443 -cipher "ALL"
Then remove the first negotiated cipher:
openssl s_client -connect google.com:443 -cipher "ALL:-TLS_AES_256_GCM_SHA384"
then remove the next
openssl s_client -connect google.com:443 -cipher "ALL:-TLS_AES_256_GCM_SHA384:-TLS_AES_256_GCM_SHA384"
then remove the next
openssl s_client -connect google.com:443 -cipher "ALL:-TLS_AES_256_GCM_SHA384:-TLS_AES_256_GCM_SHA384:-TLS_AES_256_GCM_SHA384"
then remove the next
...
Until you can no longer connect.
That will show you all the possible [mutually agreed to] ciphers you can use.
From there you can choose which cipher you would like to use most and simply force its' use.
4 Likes
While you're correct in the fact that ultimately the server decides which suite is used, the server can be configured in two ways: either choose a common suite from the top of the server suites or, choose a common suite from the top of the clients list.
4 Likes
Thanks for the inputs!
I’m running a sip client using let’sencrypt certificates. They build 4 files. privkey.pem, chain.pem, fullchain.pem, and 1 named simply “cert.pem”. The asterisk wiki is woefully inadequate about telling what files to use with asterisk / pjsip. I figured out that “priv_key_file=” gets privkey.pem. But I find conflicting information about whether “cert_file” gets “fullchain.pem” or “chain.pem” or maybe “cert.pem”? The only 1 I’ve been able to make work is “fullchain.pem”. At any rate, the “cipher=” directive must be left out completely or tls does not work with the letsencrypt cert(s) on the server! (Works Ok with Sectigo certs) (The cipher list is too large to guess) Anyone have any guidance?
4 Likes
That's the one I would use.
If about how to configure Asterisk...
I think this is not the right place to ask.
4 Likes
Success! Perseverance wins. I substituted the 2 certificates I purchased from Sectigo for the private key and certificate files. Same config - same coding, and the errors stopped. Must be some inconsistency in the files created by LetsEncrypt. Guess I'll have to purchase new certificates when these expire.
2 Likes
I very much doubt that. Even if there is a difference, it probably is not an inconsistency (which sounds negative), but probably more something that Certbot is defaulting to ECDSA nowadays and perhaps the Sectigo certs use RSA.
Unfortunately, in this entire thread I haven't seen an actual error message (with context!) or configuration files, so there's not much more we can say..
7 Likes
You are correct. I thought of that. After the update to Version 2 I converted to ECDSA because the docs said it should be Ok - wrong. I am only using as a client and they said it should be Ok unless you were running a server. Converted back to RSA and the errors cleared.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.