Ssl_error_internal_error_alert / err_ssl_protocol_error

[kghbln]

Apparently I have no idea what is going on:

ssl_error_internal_error_alert (Firefox) / err_ssl_protocol_error (Chrome)

My VirtualHost looks as follows:

<IfModule mod_ssl.c>
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_ocache(128000)

<VirtualHost *:443>
	ServerAdmin hello@example.com
	ServerName mysubdomain.example.com

	RedirectPermanent / https://www.example.com/

	SSLEngine on
	SSLUseStapling on
	SSLStaplingResponderTimeout 5
	SSLStaplingReturnResponderErrors off
	SSLCertificateFile /etc/letsencrypt/live/mysubdomain.example.com/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/mysubdomain.example.com/privkey.pem
	SSLProtocol all -SSLv2 -SSLv3
	SSLOptions +StrictRequire
	SSLHonorCipherOrder on
	SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

	ErrorLog ${APACHE_LOG_DIR}/error.log

	LogLevel warn

	CustomLog "|/usr/bin/rotatelogs -l ${APACHE_LOG_DIR}/access.log 604800" combined
</VirtualHost>
 </IfModule>

If I do not redirect to “www.example.com” the subdomain “mysubdomain.example.com” is being served without issues.

Moreover this setup worked when “www.example.com” was http. After “www.example.com” switching to https with Let’s Encrypt I start to get this error. I do not control “www.example.com” but only “mysubdomain.example.com” so I am unaware of their setup.

Googleling for this error codes reveal a lot of stuff I guess is unrelated. I am lost right now.

[stevenzhu]

Hi,

This is a domain specific case… Can you please show us your domain?

Thank you

[kghbln]

Talk about obfuscation: wiki.xmlab.org

[kghbln]

Interesting that it is working for you. I only have Firefox and Chrome at hand and even after clearing data and restarting them I continue to get my issue. Probably another case of these two degrading

openssl s_client -connect wiki.xmlab.org:443

CONNECTED(00000003)
140545442797208:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:769:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 7 bytes and written 305 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1527669232
Timeout : 300 (sec)
Verify return code: 0 (ok)

I guess the solution is: whatever, we should not care about browsers going berserk.

[stevenzhu]

@kghbln

routines:SSL23_GET_SERVER_HELLO:tlsv1

-----------look at response below mine... my browser is outdated-------------------
This is a problem...

Since tlsV1 is depreciated.. you should probably try to disable this..

Just use TLSv1.1 & 1.2, add v1.3 if your server supports them. (All protocols beside those 3 are depreciated)

Thank you

P.S. I'll try using the shell on my laptop to verify if your website is working.. but my phone with Chrome works.

[_az]

Your server is responding to the ClientHello message with

02 50

02 - Fatal error
50 - Decode error

A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect. This
message is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).

The server running wiki.xmlab.org appears to be running Debian Lenny. Lenny went EOL in 2012 - over 6 years ago, and only ever received OpenSSL 0.9.8.

No modern TLS client will sent a ClientHello that is compatible with the OpenSSL package on that server, which is why you receive the fatal error. (Though I may be mistaken here, because I still can't connect even when using SSLv2/SSLv3).

Edit: Another more likely theory I have is that your Apache server is configured with protocols and ciphersuites, none of which is provided by the server's ancient version of OpenSSL, so the TLS connection instantly fails due to lack of compatible protocols.

[sahsanu]

Hi @kghbln,

@kghbln

<IfModule mod_ssl.c>

Could you please show the output of this command?

apache2ctl -t -D DUMP_MODULES | grep ssl

Cheers,
sahsanu

[sahsanu]

@_az

No modern TLS client will sent a ClientHello that is compatible with the OpenSSL package on that server, which is why you receive the fatal error. (Though I may be mistaken here, because I still can’t connect even when using SSLv2/SSLv3).

I was thinking the same but I can't connect using ssl3 too... but keep in mind that apache conf for this virtualhost is denying SSLv3 so maybe you are not too far from the real problem

[jmorahan]

Are you sure that you are running Apache on port 443?

$ curl -I http://wiki.xmlab.org:443
HTTP/1.1 400 Bad Request
Server: nginx
Date: Wed, 30 May 2018 19:05:31 GMT
Content-Type: text/html
Content-Length: 264
Connection: close

Perhaps you have some kind of proxy setup?

[kghbln]

Thanks at all for your replies. This is awesome. You all rock! This helped me guessing what the issue could be.

First of all: The server holding the VirtualHost for “wiki.xmlab.org” is a Debian 8, moreover Apache is run on port 443. So the server should be fine.

As a matter of fact if I do not redirect “wiki.xmlab.org” to “www.xmlab.org” the page is being served fine, i.e. without any issues and I even get a Qualys A+ rating. Since the issue only started after “www.xmlab.org” switched to https I now come to believe that all the issues originate from the server serving “www.xmlab.org” which I do not control. I do not even know their setup so they might be using antedeluvian software.

Probably the issue is that I require more security with my redirect I configured that the server I am redirecting to can handle. So I will now configure a much less secure redirect and see what will happen

What is utterly irritating in my theory is that the browsers emits issues for “wiki.xmlab.org” whereas the issue is originating and to find at “www.xmlab.org”.

[_az]

@kghbln

First of all: The server holding the VirtualHost for “wiki.xmlab.org” is a Debian 8, moreover Apache is run on port 443. So the server should be fine.

My bad, sorry for wasting your time. I was fooled by this and should have known better .

That's very curious about the redirects. They shouldn't affect each other in any way.

Your site (wiki.xmlab.org) still fails to establish a TLS session though, independently of any redirects (t fails before the server even knows what the HTTP request is).

I believe that jmorahan is on the money. nginx that is configured to listen on port 443 without any certificates can also alert in this way.

You can confirm by checking who is actually bound to 443 (despite Apache being configured for 443, nginx may be fighting for it, which could also explain why it worked for an intermittent period (possible between service restarts)):

sudo ss -tlnp | grep 443

[kghbln]

Your site (wiki.xmlab.org) still fails

I still have to reconfigure. Two unrelated immediate issues in the meantime which held me up. This day is a disaster for me. Truely.

Running sudo ss -tlnp | grep 443 reveals that only Apache is bound to 443. Nginx is not even installed on the server.

I still believe in my redirect theory but I am obviously not solid on this.

[_az]

. I have another theory (I’m really sorry, tell me if you want to stop).

I think your web host may be intercepting all traffic on port 443 in that subnet and redirecting it to their own nginx server.

My evidence to support this is that the entire 217.160.223.0/24 subnet (which your server belongs to) responds with an HTTP 400 nginx banner if you send a plain-text HTTP request on port 443, in the exact manner as your server, with the exact TLS alert bytes (02 50) as your server.

[kghbln]

So my theory has proven wrong. Even adding an “old” configuration does not make the error go away.

Your theory sounds good to me however it does not make a lot of sense from my perspective. I have the same configuration for many other domains on the same server where it is working. The only difference in this case is that the domain I am redirecting to is on a different server.

In the end I could not be bothered any longer. The original aim was to take the sub domain off the air. As an extra the redirect would have been nice but this is not imperative to me. It would have been nice to get things rolling here but in the end it does not seem to be a LE issue anyways and the time put into it by all you cool guys and me is no longer justifiable.