My domain is: MrEngineer13.com
I ran this command: certbot-auto
It produced this output:success
My web server is (include version):Nginx 1.10.3
The operating system my web server runs on is (include version): Ubuntu 14.04
My hosting provider, if applicable, is: digital ocean
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): certbot 1.4.0
I had LE working for the previous url. I’m trying to update, changing server code location but not url. I get a 502 ERR_SSL_PROTOCOL_ERROR in my browser when I visit in the browser but 200 when I curl -I to the site.
I removed the www. prefix and removed the A DNS record. Here’s the DNS suggestions: https://check-your-website.server-daten.de/?q=mrengineer13.com
What do you think is causing this?
you have a wildcard dns entry
*.mrengineer13.com -> CNAME mrengineer13.com
so your www version has an IP address.
But that's not the problem.
The problem is curious. My FireFox says:
Never seen that error.
Local Chrome says
But "check-your-website" uses a headless Chrome to create the screenshot, there is a screenshot.
Check, if you are able to change that error:
PS: Looks that this old topic
has an answer.
3.3. NewSessionTicket Handshake Message
This message is sent by the server during the TLS handshake before
the ChangeCipherSpec message. This message MUST be sent if the
server included a SessionTicket extension in the ServerHello. This
message MUST NOT be sent if the server did not include a
SessionTicket extension in the ServerHello.
Your server is not sending the extension in its ServerHello, but it does later in the handshake. Its TLS implementation appears to be non-conformant.
Are you using OpenSSL? What OpenSSL version is your webserver linked against:
I believe the reason is that cURL, by default, does not enable the SessionTicket extension in its ClientHello message.
But your browser does.
The wrong behavior by your webserver's TLS implementation only occurs in the latter case.
Edit: As @JuergenAuer posted, this post appears to contain the explanation for why it's happening and how you can fix it:
@JuergenAuer I’m impressed that you found that answer faster than I did. I have debugging this issue for a while so incase anyone finds this I was installing a Ghost blog and a they specialize a SSL params file with ssl_session_tickets getting toggled to on.
Checking with different browsers is helpful. The Chrome error message is too unspecific, so that doesn’t really help.
The FireFox error is specific - and lists the older topic on top.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.