Err_ssl_protocol_error

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:pharmapacmis.com

I ran this command:Chrome, Firefox, Edge

It produced this output:ERR_SSL_PROTOCOL_ERROR

My web server is (include version):IIS v10.0.17763.1

The operating system my web server runs on is (include version):Windows Server 2019 v1809

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):win-acme v2.1.17.1065 (release, trimmed, standalone, 64-bit)

Hi

I'm looking for some help please.

I have a php web app running on the above server which I can reach via HTTP but not HTTPS.

Edge gives `The connection for this site is not secure

pharmapacmis.com sent an invalid response.

  • [Try running Windows Network Diagnostics](javascript:diagnoseErrors()).

ERR_SSL_PROTOCOL_ERROR`

Firefox gives SSL_ERROR_INTERNAL_ERROR_ALERT

I've spent the last day or so googling this issue but have struck out.

Running check-your-website.server-daten.de shows SecureChannelFailure - The request was aborted: Could not create SSL/TLS secure channel.

On the server TLS 1.2 is the only protocol enabled.

nmap cipher scan shows:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-02 11:38 GMT Daylight Time
Nmap scan report for pharmapacmis.com (192.168.10.51)
Host is up (0.00s latency).

PORT    STATE SERVICE   VERSION

443/tcp open  ssl/https

 http-server-header: 
   Microsoft-HTTPAPI/2.0
_  Microsoft-IIS/10.0

 ssl-enum-ciphers: 

   TLSv1.2: 

     ciphers: 
       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 3072) - C

     compressors: 

       NULL

     cipher preference: server

     warnings: 

       64-bit block cipher 3DES vulnerable to SWEET32 attack

       Key exchange (dh 2048) of lower strength than certificate key

_  least strength: C

I'm stuck as what to check next.

Any help would be most appreciated.

Jake

1 Like
2

Welcome to the Let's Encrypt Community, Jake :slightly_smiling_face:

I suspect that your certificate might not be installed correctly. Possibly a private key mismatch? Try reinstalling your certificate.

It could also be that the list of supported cipher protocols is too restrictive.

https://www.ssllabs.com/ssltest/analyze.html?d=pharmapacmis.com

3

Are you able to view the site from within its' network (or from itself)?
If so, then the firewall (or other system) may be to blame.
If not, then start there - the site must be functional.
To that end... was it ever functioning securely? (if so, provide details on when it stopped)
How did it obtain the most recent cert?
How was the cert applied within IIS?
When was the server last rebooted?

1 Like
5

I think you have accidentally limited the TLS cipher suite too much, did you use IIS Crypto? If not, try Nartac Software - IIS Crypto

First use the Best Practices option, restart and check everything is working, then assuming you just want to support TLS 1.2, uncheck the TLS 1.0 and 1.1 under the Server Protocols section (just leave client protocols on) and restart again.

2 Likes
6

Thanks for chiming-in, @webprofusion. I was going to tag you, but I figured I'd take a crack at it first. :slightly_smiling_face:

1 Like
7

:crossed_fingers:
That will fix this problem.
It has a very high probability.

Otherwise, it could be in the implementation - where IIS is sometimes very peculiar about how certs are added and used.

1 Like
8

Yes if there is an issue with the private key storage (wrong account user used to renew the cert etc) you can also get weird/broken stuff happening. So yes, that could also be the problem. win-acme will otherwise do a good job of updating bindings etc but it can't defeat OS level permissions.

2 Likes
9

Hi everyone

Many thanks for taking the time to reply.

I'll summarise what I've done since your replies:

I installed NARTAC IIS Crypto tool.

The before settings

After Best Practice

I then rebooted the server (which I've done several times over the last few days).

I then re-ran win-acme and regenerated the certificate

New Certificate

New Certificate details

I restarted the server.

Still the same error when attempting an SSL connection :frowning_face:

I re-ran NMAP on the server - I have a host file entry for domain pointing at the server's IP address

Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-03 12:01 GMT Daylight Time
Nmap scan report for pharmapacmis.com (192.168.10.51)
Host is up (0.00s latency).

PORT    STATE SERVICE   VERSION
443/tcp open  ssl/https

 http-server-header: 
   Microsoft-HTTPAPI/2.0
_  Microsoft-IIS/10.0

 ssl-enum-ciphers: 

   TLSv1.0: 
     ciphers: 
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
     compressors: 
       NULL
     cipher preference: server

   TLSv1.1: 
     ciphers: 
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
     compressors: 
       NULL
     cipher preference: server

   TLSv1.2: 
     ciphers: 
       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp384r1) - A
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A
       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
     compressors: 
       NULL
     cipher preference: server
_  least strength: A

Running the same command from home - nmap -sV -p 443 --script ssl-enum-ciphers pharmapacmis.com - I only receive the following output:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-03 12:00 GMT Summer Time
Nmap scan report for pharmapacmis.com (87.224.124.107)
Host is up (0.030s latency).
rDNS record for 87.224.124.107: 87-224-124-107.spitfireuk.net

PORT    STATE SERVICE    VERSION

443/tcp open  ssl/https?

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 19.70 seconds

Is this to be expected?

Running this command -nmap -p 443 --script ssl-cert pharmapacmis.com -on the server gives this output:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-07-03 12:09 GMT Daylight Time
Nmap scan report for pharmapacmis.com (192.168.10.51)

Host is up (0.00s latency).

PORT    STATE SERVICE

443/tcp open  https

 ssl-cert: Subject: commonName=pharmapacmis.com
 Subject Alternative Name: DNS:pharmapacmis.com
 Issuer: commonName=R3/organizationName=Let's Encrypt/countryName=US
 Public Key type: rsa
 Public Key bits: 3072
 Signature Algorithm: sha256WithRSAEncryption
 Not valid before: 2021-07-03T07:34:31
 Not valid after:  2021-10-01T07:34:30
 MD5:   bd87 7fd5 340c 2689 fd1d a73d 0e22 3b7f
_SHA-1: 190d d1ba 89bc 7d85 353c 53d4 105e a5a7 dbf6 5e7e

Just double checking 443 on the server - looks ok to me.

A bit of background.

This server was created by the IT department over a year ago. The only purpose is to run this web application which is php/MS SQL. I have admin login to server however I have no access to certain setting such as gpedit.msc. The server was setup plain vanilla - no special requirements. I have installed Let's Encrypt on several Windows boxes in the past without any issues.

One interesting thing is that as I said above I've created a hosts file entry for this domain pointing at the server's IP address and if I access via Chrome on the server I do get a secure connection. However I've been told that trying to connect to it via https from the internal lan results in the same error.

Looking at the IIS logs I see no entries at all for 443 traffic - only 80 - unless from the local server IP.

Looking at the server's event viewer I see plenty of SCHANNEL 36874 errors - An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed.

Could this be where the issue lies? Why does nmap show the ciphers and this error is still happening?

Stumped.

My skills are in db dev so thanks for your patience with me.

Again any help most appreciated.

Jake

1 Like
10

SNI?
When NMAP connects to the IP, the response is as expected.
When NMAP connects to the NAME, the response is NOT as expected.
The only difference is the NAME being requested?
Unfortunately, I can't confirm the same results from the Internet.
Where both (name and IP) return:
error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
[regardless of TLS version used]

So...
There seem to be more than one problem.

  1. (as per your NMAP) is visible locally and handles the IP differently than the NAME - and can only be done from within the server.
  2. (as per CURL) is visible from the Internet and affects both the IP and the NAME - this implies there may be another system in line that affects TLS connections.

OR

All of these are only symptoms and the real problem is has yet to show itself clearly.

1 Like
11

I'd guess that externally this domain is going through a firewall or proxying gateway. So if you access it using a local IP it skips that, but externally tcp port 80 gets through (so http validation works),but for tcp port 443 the traffic gets mangled by the security device (or possibly even forwarded to the wrong internal machine).

2 Likes
12

Hi all

Sorry for the delay in getting back.

I managed to get one of company's IT staff who has detailed knowledge of the network topology (he was on holiday last week).

And you were correct: there is a proxy server in the network handling 443 traffic - Caddy Proxy - that does the de-encryption and send the traffic as plain http to servers.

He reconfigured it and it has grabbed a Let's Encrypt certificate for the domain. I removed the https bindings on IIS and the only URL Rewrite rule I have left is www to non-www.

All is now working as expected.

Many thanks for all your help - I have learned a fair bit over the last few days.

Cheers

Jake

3 Likes
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.