Solved Microsoft TLS 1.2 cipher suit not compatible with OpenSSL ?

jvdwilk · Oct 20, 2021

I am trying to get a working 'autodiscover' for my hosting servers.
Seeing a consistent failing from the Windows 10 'Mail' client, which relies on the 'autodiscover' of Outlook, while my 'autodiscover' works fine with older MS Outlook clients, I started testing my 'autodiscover' with Microsofts https://testconnectivity.microsoft.com/tests/O365Ola/input service.

There I finally get an error on there being no compatible cipher suite between the cipher suits Microsoft offers ( https://docs.microsoft.com/en-gb/mi...-details-about-encryption?view=o365-worldwide ) and my 'autodiscover' website.
Microsoft only offers TLS 1.2 at the moment. My server offers TLS 1.2 and 1.3, with the default 'ssl_configuration=intermediate' in the options.conf of Custombuild.
But also tinkering with the SSL cipher suits didn't give me any situation where I had a matching cipher suite with the ones that Microsoft offers.

Looking at the availble TLS v1.2 cipher suites ( https://www.mkssoftware.com/docs/man1/openssl_ciphers.1.asp ) I was expecting a match with either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-AES256-GCM-SHA384.
Putting these in the configuration, and checking through ssllabs.com, this gave me zero TLS v1.2 cipher suits;
nothing for TLS v1.2.

Now, am I missing something, or is the Microsoft cipher suite indeed incompatible with what OpenSSL can offer?
The server at which I was testing things is rather default, fully updated, running CloudLinux 8 and DirectAdmin, installed from Custombuild.
Setup is with Apache / Nginx proxy
OpenSSL 1.1.1g FIPS 21 Apr 2020

I hope Microsoft won't be applying these ciphers suites at their mail servers, and either not delivering email at 'incompatible servers' anymore, or just sending over open connections?

Richard G · Oct 22, 2021

The Letsencrypt script changes in the past can have caused some issues.

Check your server with this command:
nmap --script ssl-enum-ciphers -p 465 localhost

You should get an output like this:

Code:

Nmap scan report for localhost (127.0.0.1)
Host is up (0.000038s latency).
rDNS record for 127.0.0.1: localhost.localdomain
PORT    STATE SERVICE
465/tcp open  smtps
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors: 
|       NULL
|_  least strength: strong

Be aware of the TLS_DHE_RSA lines. If they are missing, that could cause issues. There is a solution for this too.

jvdwilk · Oct 22, 2021

Nope, not that... :

Code:

nmap --script ssl-enum-ciphers -p 465 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-10-22 23:05 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000095s latency).
Other addresses for localhost (not scanned): ::1

PORT    STATE SERVICE
465/tcp open  smtps
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (ecdh_x25519) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.56 seconds

But it is definetly something Let's Encrypt related
Somewhere I read an explanation:

RSA ciphers can only be used if the certificate has an RSA public key. ECDSA ciphers can only be used of the certificate has an ECC public key. If you want to use the ciphers required then you have to change the certificate to one with an RSA public key.

This triggered me to place an externally created keypair, and this specific keypair IS showing a 'full set' of RSA ciphers on this specific certificate.
At least it is for TLS 1.2, still not so much for TLS 1.3 ...

Code:

output from SSLlabs.com:

# TLS 1.3 (suites in server-preferred order)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_SHA256

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

So, the next challenge is now how to re-install Let's Encrypt... (not just a quick script update, but fully remove and re-install) and then see what happens afterwards.

Richard G · Oct 23, 2021

jvdwilk said:
Nope, not that... :

Yes it is that as far as I can see. As you can see from your output, you are missing the TLS_DHE_RSA ciphers.
You only have the ECDSA ciphers.

I had this issue before and it's easy to fix.

Try this:

cd /usr/local/directadmin/custombuild
./build update
./build letsencrypt
cd /usr/local/directadmin/scripts
./letsencrypt.sh request_single your.hostname.com 4096

If you give the nmap command after this, you will see you will also have the TLS_DHE_RSA ciphers which should be present.

ikkeben · Oct 23, 2021

Richard G said:
./letsencrypt.sh request_single your.hostname.com 4096[/ICODE]

for multiple see old docs maybe also new somewhere

https://help.directadmin.com/item.php?id=645

don't know if that does then also dovecot as with single ???
See single:

which will also install the new cert/key/ca files in all respective global places for apache, dovecot, exim, ftp, and DirectAdmin.
NOTE The hostname value, eg: your.hostname.com must match the "servername" value set in the directadmin.conf, or it will not be in hostname mode, but User domain mode instead.

Richard G · Oct 23, 2021

ikkeben said:
for multiple see old docs maybe also new somewhere

Yeah but that is old stuff. It's better to change the hostname and if there are other domains which need this it can be done from DA. Also one can choose from there if they want to use ECDSE or such.

The single hostname line should fix the issue already.

Hostname should match the set servername anyway.

jvdwilk · Oct 24, 2021

Yes, that. Exactly that. Thank you Richard ..! A lot!

Code:

nmap --script ssl-enum-ciphers -p 465 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-10-24 11:11 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000070s latency).
Other addresses for localhost (not scanned): ::1

PORT    STATE SERVICE
465/tcp open  smtps
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (ecdh_x25519) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.84 seconds

But now...
I get a correct certificate on the hostname, but when re-creating a new certificate for a hosted domain (through the DA contol panel, not from command line), it doesn't change anything.
Still - after rebooting the server and after requesting a new certificate from Let's Encrypt - I get an 'incomplete' certificate which only supports the ECDSA based cipher as before, and not the RSA ones...

Just when I thought I was done with this...

jvdwilk · Oct 24, 2021

Really scratching my head now. Even when I create a new hosting account (for testing) and generate a Let's Encrypt certificate for it, it does not get any RSA based ciphers, while earlier the ./letsencrypt.sh request_single your.hostname.com 4096 did give me a certificate with RSA based ciphers.

jvdwilk · Oct 24, 2021

Suspecting some bugs now, either in DA or in the letsencrypt.sh script.
This is going over my head now:

cd /usr/local/directadmin/scripts
./letsencrypt.sh request_full <test_account_domain_name> 4096
is giving warnings on the <test_account_domain_name> subdomains

Code:

./letsencrypt.sh request_full <test_account_domain_name> 4096
mail.<test_account_domain_name>,www.<test_account_domain_name> was skipped due to unreachable http://mail.<test_account_domain_name>,www.<test_account_domain_name>/.well-known/acme-challenge/ file.
ftp.<test_account_domain_name>,www.<test_account_domain_name> was skipped due to unreachable http://ftp.<test_account_domain_name>,www.<test_account_domain_name>/.well-known/acme-challenge/ file.
smtp.<test_account_domain_name>,www.<test_account_domain_name> was skipped due to unreachable http://smtp.<test_account_domain_name>,www.<test_account_domain_name>/.well-known/acme-challenge/ file.
pop.<test_account_domain_name>,www.<test_account_domain_name> was skipped due to unreachable http://pop.<test_account_domain_name>,www.<test_account_domain_name>/.well-known/acme-challenge/ file.
2021/10/24 13:23:06 [INFO] [<test_account_domain_name>, www.<test_account_domain_name>] acme: Obtaining SAN certificate
2021/10/24 13:23:07 [INFO] [<test_account_domain_name>] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/42843627530
2021/10/24 13:23:07 [INFO] [www.<test_account_domain_name>] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/42857396890
2021/10/24 13:23:07 [INFO] [<test_account_domain_name>] acme: authorization already valid; skipping challenge
2021/10/24 13:23:07 [INFO] [www.<test_account_domain_name>] acme: authorization already valid; skipping challenge
2021/10/24 13:23:07 [INFO] [<test_account_domain_name>, www.<test_account_domain_name>] acme: Validations succeeded; requesting certificates
2021/10/24 13:23:09 [INFO] [<test_account_domain_name>] Server responded with a certificate for the preferred certificate chains "ISRG Root X1".
Certificate for <test_account_domain_name>,www.<test_account_domain_name> has been created successfully!

But it IS creating a RSA based SSL certificate !
Even if only for the <test_account_domain_name> and www.<test_account_domain_name> domains.

Then trying the same from DirectAdmin web CP requesting a Let's Encrypt SSL certificate for the same <test_account_domain_name> it will create a certificate for me without complaining about any of the subdomains and give me a certificate inclusive for all separate sub domains (not wildcard, separate for mail, ftp, smpt, pop, and what's more). BUT this certificate is again only for the ECDSA based ciphers.

And consistent results from testing the same with nmap and through SSLlabs.com.

It's driving me nuts...

@smtalk - any ideas on this please?

jvdwilk · Oct 25, 2021

of je stopt de stekker er in... (or you plug in into a socket)

Well... with DA support I was able to find the bug... it was located between my ears.

I never realised that the setting for 'key length' in the GUI when creating a new SSL keypair also controlled the cipher type. But it does.
All I had to do was select another cipher, and it would work. And it does...

Sorry for waisting everyone's time on this. Thanks again Richard..!

Richard G · Oct 26, 2021

jvdwilk said:
it was located between my ears.

Do they support that? Would be nice, I know I have some bugs there too.

Nice you found it, I thought you knew that one about the cipher type.

Graag gedaan hoor!

Solved Microsoft TLS 1.2 cipher suit not compatible with OpenSSL ?

jvdwilk

Verified User

Richard G

Verified User

jvdwilk

Verified User

Richard G

Verified User

ikkeben

Verified User

Richard G

Verified User

jvdwilk

Verified User

jvdwilk

Verified User

jvdwilk

Verified User

jvdwilk

Verified User

Richard G

Verified User