I’m trying to get apache2 to work with a certificate (selc created) on Ubuntu 20.
When I try to open, with Chrome, the endpoint (https://local.pretzel.com/editor) I get:
This site can’t provide a secure connection
local.pretzel.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
Spend the whole night on this, could use some help to understand what I did wrong and how to propely debug this.
// Apache conf
httpd.conf in /etc/apache2/
LoadModule mpm_prefork_module libexec/apache2/mod_mpm_prefork.so
LoadModule log_config_module libexec/apache2/mod_log_config.so
LoadModule mime_module libexec/apache2/mod_mime.so
LoadModule dir_module libexec/apache2/mod_dir.so
LoadModule authz_core_module libexec/apache2/mod_authz_core.so
LoadModule unixd_module libexec/apache2/mod_unixd.so
LoadModule rewrite_module libexec/apache2/mod_rewrite.so
LoadModule php7_module libexec/apache2/libphp7.so
LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
LoadModule ssl_module libexec/apache2/mod_ssl.so
User _www
Group _www
DirectoryIndex index.html
ErrorLog "/var/log/apache2/error_log"
LogFormat "%h %l %u %t "%r" %>s %b" common
CustomLog "/var/log/apache2/access_log" common
TypesConfig /etc/apache2/mime.types
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
DirectoryIndex index.html index.php
<Directory /home/prtz/workspace/frontend/build>
Options Indexes FollowSymLinks
Require all granted
AllowOverride All
</Directory>
ServerName local.pretzel.com
Listen 443
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
SSLHonorCipherOrder on
SSLProtocol all -SSLv3
SSLProxyProtocol all -SSLv3
SSLPassPhraseDialog builtin
SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout 300
<FilesMatch ".(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<VirtualHost *:443>
DocumentRoot "/home/prtz/workspace/frontend/build"
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/etc/apache2/local.pretzel.com.crt"
SSLCertificateKeyFile "/etc/apache2/local.pretzel.com.nopass.key"
ServerName local.pretzel.com
</VirtualHost>
/etc/apache2/sites-available/default-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
ServerName local.pretzel.com
DocumentRoot "/home/prtz/workspace/frontend/build"
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/etc/apache2/local.pretzel.com.crt"
SSLCertificateKeyFile "/etc/apache2/local.pretzel.com.nopass.key"
<FilesMatch ".(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</IfModule>
/etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:443>
ServerName local.pretzel.com
</VirtualHost>
nmap —script ssl-enum-ciphers -p 443 local.pretzel.com:
nmap --script ssl-enum-ciphers -p 443 local.pretzel.com
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-28 21:27 PDT
Nmap scan report for local.pretzel.com (127.0.0.1)
Host is up (0.000064s latency).
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 15.49 seconds
cat /etc/hosts:
cat /etc/hosts
127.0.0.1 local.pretzel.com
127.0.0.1 localhost
127.0.1.1 ubuntu
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
created certificate with
openssl openssl req -newkey rsa:2048 -x509 -nodes \
-keyout local.pretzel.com.key \
-new \
-out local.pretzel.com.crt \
-subj /CN=local.pretzel.com \
-reqexts SAN \
-extensions SAN \
-config <(cat /usr/lib/ssl/openssl.cnf \
<(printf '[SAN]nsubjectAltName=DNS:local.pretzel.com')) \
-sha256 \
-days 3650
sudo openssl rsa -in local.pretzel.com.key -out local.pretzel.com.nopass.key
sudo mv *.key *.crt /etc/apache2
added cert to /usr/local/share/ca-certificates/
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping duplicate certificate in server.pem
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
// check certificate
openssl verify local.pretzel.com.crt
local.pretzel.com.crt: OK
// check with openssl connect
openssl s_client -connect local.pretzel.com:443 -CApath /etc/ssl/certs
CONNECTED(00000003)
140129913148736:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 311 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
// check firewall
sudo ufw status
[sudo] password for prtz:
Status: active
To Action From
-- ------ ----
Apache ALLOW Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
443/tcp ALLOW Anywhere
Apache (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
// using curl with https
curl https://local.pretzel.com
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
while without https it will return the «Apache2 Ubuntu Default Page: It works»
curl https://local.pretzel.com
So when I go to https://example.org I get ERR_SSL_PROTOCOL_ERROR. I have checked my Security Groups on AWS (ec2/ubuntu 16.04 server) and I do in fact have port 443 open on both TCP/HTTPS. My only sites-enabled is default-ssl.conf and here are the contents:
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
<IfModule mod_ssl.c>
ErrorLog /var/log/apache2/ssl_engine.log
LogLevel debug
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
SSLCipherSuite HIGH
SSLProtocol all
SSLHonorCipherOrder On
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/mycert.pem #note I also tried this with a .crt file because I have both
SSLCertificateKeyFile /etc/ssl/private/mykey.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch ".(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]"
# nokeepalive ssl-unclean-shutdown
# downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
As of right now /var/log/apache2/ssl_engine.log is empty .. I did make it to see if that was the problem and still nothing wrote to it. I read somewhere earlier to try http://example.org:443 and I did that and got a 404: Not found page, but it did load instead of getting the This site can't provide a secure connection message. I also uncommented the extension=mod_ssl.dll (or similar) line in php.ini to no avail. Not really sure what steps to take next. I tried generating new key/cert combo to see if that was the issue but didn’t fix anything. Also ran openssl commands to check if they matched and didn’t get any errors.
One other thing I tried is this: sudo openssl s_client -connect localhost:443
And result: 139878660703896:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
Приветствую, уважаемые форумчане! Проблема возникла довольно внезапно, всё что пришло в голову сам уже перепробовал, но знаний в этой области катастрофически не хватает, посему обращаюсь за помощью к вам.
На VPS установлена панель VestaCP, есть несколько сайтов, пара тестовых и один основной рабочий. Пару дней назад забыл продлить его домен, в итоге поимел себе следующую проблему: непродлённый домен отрубился, сайт перестал работать, после продления появилась ошибка SSL (ERR_SSL_PROTOCOL_ERROR), перевыпустил сертификат средствами панели — не помогло.
Если проверять здесь: https://www.ssllabs.com/ssltest/analyze.html
Получаю ответ «Assessment failed: No secure protocols supported»
Насколько я понимаю это говорит о том что сервер даже не пытается отдавать шифрованные данные клиенту..
При этом в панели SSL для конкретного домена включен. Работает всё на связке NGINX+PHP-FPM, используемая ОС Ubuntu 16.04.6 LTS, сайты работают на CMS WordPress. В настройках WordPress home и siteurl указаны через https://
Ранее была проблема с ошибками конфигурации NGINX:
nginx: [warn] the «ssl» directive is deprecated, use the «listen … ssl» directive instead in /home/user/conf/web/domain1.ru.nginx.ssl.conf:10
nginx: [warn] the «ssl» directive is deprecated, use the «listen … ssl» directive instead in /home/user/conf/web/domain2.ru.nginx.ssl.conf:10
nginx: [warn] the «ssl» directive is deprecated, use the «listen … ssl» directive instead in /home/user/conf/web/domain3.ru.nginx.ssl.conf:10
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Поправил соответствующие файлы, указал директиву «listen 443 ssl;» директиву «ssl on;» откомментировал подставив перед ней #
Теперь в выводе nginx -t ошибок нет:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Кстати ssl в данный момент не работает для всех доменов, хотя раньше работал и на тестовых. Сертификаты везде от Let’s Encrypt.
В error.log по домену на запрос любой страницы ошибка:
2019/03/16 13:54:16 [crit] 8372#8372: *714 open() «/home/user/web/domain.ru/public_html/» failed (13: Permission denied), client: 185.234.218.33, server: domain.ru, request: «GET /?author=4 HTTP/1.1», host: «domain.ru»
Шаблон в панели установлен wordpress2….куда копать совсем не понимаю, дайте пожалуйста какое-нибудь направление! 
I tried to install letsencrypt on my apache2 server (running on Ubuntu 16.04). It seems to work fine but for some reason i got the following error on my website:
ERR_SSL_PROTOCOL_ERROR
i cant figure out what’s wrong and i hope you’ll be able to help me.
Here is my vhost:
<VirtualHost *:80>
ServerName debout-les-idees.fr
ServerAlias www.debout-les-idees.fr
RewriteEngine on
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
<IfModule mod_ssl>
<VirtualHost *:443>
ServerName debout-les-idees.fr
ServerAlias www.debout-les-idees.fr
DocumentRoot /var/www/DLI.fr/public
<Directory /var/www/DLI.fr/public>
Options -Indexes
AllowOverride all
Order allow,deny
allow from all
</Directory>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/debout-les-idees.fr/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/debout-les-idees.fr/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/debout-les-idees.fr/chain.pem
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
LogLevel warn
ErrorLog ${APACHE_LOG_DIR}/www.debout-les-idees.fr-error.log
CustomLog ${APACHE_LOG_DIR}/www.debout-les-idees.fr-access.log combined
</VirtualHost>
</IfModule>
And here is my error.log:
Tue Dec 11 06:25:03.530356 2018] [mpm_prefork:notice] [pid 26402]
AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured -- resuming
normal operations
[Tue Dec 11 06:25:03.530397 2018] [core:notice] [pid 26402] AH00094:
Command line: '/usr/sbin/apache2'
And if it can help you here is my ports.conf file:
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
NameVirtualHost *:80
Listen 80
<IfModule mod_ssl.c>
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
NameVirtualHost *:443
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>
Thanks a lot guys, i believe in you ^^
If your WordPress website fails to load over a secure connection due to an error such as ERR_SSL_PROTOCOL_ERROR then you’re in the right place. In this article, we’ll explain what this type of error means and walk you through the steps needed to fix it to get your site back up and running!
This error can be caused by various issues with your website server or your local computer, or even a combination of both. It’s commonly experienced in Chrome, but it can vary based on the browser you’re using.
- What is a Secure Connection Anyway?
- Taking Stock of Your Site
- Solutions to ERR_SSL_PROTOCOL_ERROR
Is your WordPress site giving you the ERR_SSL_PROTOCOL_ERROR? 😰We’ve got you covered with the complete list of things to do to fix it!Click to Tweet
Check Out Our Video Guide to Fixing SSL Connection Errors
Google Chrome
In Google Chrome this error will show as ERR_SSL_PROTOCOL_ERROR and will say that the domain sent an invalid response.
This site can’t provide a secure connection.
Microsoft Edge
In Microsoft Edge, it will simply show as “Can’t connect securely to this page” (as seen below). However, the next part of the error is what is helpful.
This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.
Mozilla Firefox
In Mozilla Firefox ERR_SSL_PROTOCOL_ERROR triggers a warning about the failed secure connection as seen below.
Warning: Potential Security Risk Ahead
Unlike Google Chrome and Microsoft Edge, the Firefox error page offers a little more information about possible courses of action should this type of error occur.
8 Things to Do When Experiencing ERR_SSL_PROTOCOL_ERROR:
- Clear SSL State.
- Verify SSL Certificate (DNS settings haven’t fully propagated yet).
- Check the System Time and Date.
- Clear Browser Cache and Cookies.
- Disable Browser Extensions.
- Update Browsers to Latest Version.
- Update Your Operating System.
- Temporarily disable Antivirus and Firewall (Sometimes these software might incorrectly block a secure connection).
What is a Secure Connection Anyway?
If you’re wondering what a webpage loading over secure connection is, then a little background information may be helpful.
You may have noticed that website addresses typically begin with HTTP or HTTPS. These are called protocols which are basically a set of rules for determining how web pages are transmitted from the server (where your website is located) to the browser. HTTPS is a secure protocol based on HTTP and is widely used as it has a number of significant advantages including improved SEO and a high level of security.
A downside to using HTTPS is that there are strict rules in place that need to be adhered to before a secure webpage can be displayed. This means that there’s more that can potentially go wrong compared to non-secure HTTP connections.
One of these requirements needed to make a website work with an HTTPS connection is that you must have a valid SSL certificate installed and configured correctly. Invalid SSL certifications can cause problems preventing users from accessing websites. For example, the “Your Connection is Not Private” error.
When your SSL certificate is working properly then a padlock icon is displayed next to the website address in the browser window. If you click on the padlock a popup window displays a confirmation notice that the website has been loaded over a secure connection and any information sent to the server from your website (e.g. form submissions) will also be transmitted securely.
Most website visitors these days have come to expect HTTPS connections over the entire site. Long gone are the days when the only secure pages on your site were limited and specific areas such as the admin, login, and shopping cart.
Traditionally, it was deemed unnecessary (and overkill) to use a secure connection site-wide in-part due to the prohibitive expense of SSL certificates. All that has changed now though with free SSL certificates being readily available, so HTTPS has become standard practice.
Taking Stock of Your Site
Before we take a look at some of the possible underlying root causes of ERR_SSL_PROTOCOL_ERROR, it would be useful for you to take a moment and recall any recent changes that may have been made to your site.
Usually, once you have a secure connection up and running it’s pretty stable. And most of the time, issues occur when something has been changed either on the server side for existing websites, or when setting up your site for the first time. If the requested site does not exist, you can expect to see the DNS_PROBE_FINISHED_NXDOMAIN error.
Have you recently changed hosts or tried to install a new SSL certificate? This is the most common reason for this error to occur.
Being aware of recent site changes may give you a strong indication of what could be causing the secure connection issue.
Solutions to ERR_SSL_PROTOCOL_ERROR
Work through the solutions in the following sections one-by-one until your secure connection error is fixed.
This type of error can occur locally, or on the server, and so some steps focus on your local computer/browser settings, while other steps consider problems related to the server setup and how the SSL certificate has been configured.
Clear SSL State
The first thing to try is clearing the SSL state in Chrome. The browser stores SSL certificates in a cache to speed up subsequent connections once an initial secure connection has been made to a website.
This is to optimize page load times as otherwise, every HTTPS request would require the SSL certificate to be downloaded and authenticated which wouldn’t be great for performance.
When migrating a website to Kinsta, problems may arise when the DNS settings have been updated to point at Kinsta servers and the free SSL certificate from Let’s Encrypt has been installed.
After the DNS settings have propagated and the site is accessed in a browser a secure connection, the error can sometimes be displayed due to the browser cache storing an outdated version of the SSL certificate.
To fix this, try clearing the SSL state cache. Once done restart your browser and try connecting to your website again.
If you’re using macOS see these instructions on how to delete an SSL certificate.
Verify SSL Certificate
A similar issue occurs when an SSL certificate is generated but the DNS settings haven’t fully propagated yet. In this case, the SSL certificate won’t be associated with the correct domain at the time of creation.
If you’re a Kinsta client, you can check if your SSL certificate is installed by visiting the MyKinsta dashboard and making sure there is a green checkmark next to the certificate settings.
You can also perform a site-wide scan with an online SSL checker tool to verify that there are no issues with your SSL certificate. This type of check is pretty reliable and bypasses your browser cache to determine if the certificate is valid.
We recommend using the SSL check tool from Qualys SSL Labs which is the one we use internally at Kinsta.
Simply enter your domain into the Hostname field and click on the Submit button. Once the scan is complete a report is displayed with the results of the SSL certificate checks. If all is well you should see something like this:
You can find more in-depth information in our guide on how to check if your SSL certificate is working properly.
Check the System Time and Date
If the SSL certificate is valid and clearing SSL state doesn’t work, then it’s time to look at your local computer to identify the source of your ERR_SSL_PROTOCOL_ERROR.
(Suggested reading: if you’re using legacy TLS versions, you might want to prevent ERR_SSL_OBSOLETE_VERSION Notifications in Chrome).
First, check whether the operating system time and date are set correctly otherwise your SSL certificate may have problems being authenticated.
This is because SSL certificates have a fixed expiry date and, if your current system time and date aren’t correct, then it may conflict with the authentication process.
A valid time and date is always assumed when a secure connection is made, which is why it’s important to make sure the correct value is retrieved from your local system.
To check the time and date in Windows 10, press the Windows Key + X keys and select System from the popup context menu. This will bring up the Settings window.
In the Find a setting text box, start typing “time” and select Change the date and time from the dropdown options. Then, in the Date and time settings window check the time and date are correct before continuing.
On macOS, click the Apple icon in the top left corner of the screen and select System Preferences from the drop-down menu, and select Date and Time from the list.
You’ll then be able to update your system time as necessary.
Clear Browser Cache and Cookies
You can also try deleting your browser cache if it’s been a while since it was last cleared. We recommend that you also delete browser cookies too, but bear in mind that any sites you’re currently logged into will require you to log in again the next time you visit them.
Disable Browser Extensions
If you have multiple browser extensions enabled, then this could potentially be the source of the error. Temporarily disable browser extensions one-by-one to see if there’s one causing issues with HTTPS requests.
To disable Chrome extensions, click the three dots icon located towards the top right of the browser window and select More Tools > Extensions from the popup menu.
Toggle all the enabled browser extensions one at a time to disable them, accessing your site in-between each one. If an extension appears to be causing the ERR_SSL_PROTOCOL_ERROR issue, then either remove it or leave it disabled until you can find out more information on the nature of the error.
If no update is available to fix the issue, it’s probably best to remove the extension completely.
Update Browsers to Latest Version
The final browser-related step is to update Chrome to its latest version.
Running older versions of a browser increases the chances that you’ll experience secure connection issues such as ERR_SSL_PROTOCOL_ERROR.
New and updated security features are always added to modern browsers and bugs are fixed on a regular basis and keeping things up-to-date is a best practice you should follow.
The Chrome browser makes this easier as it checks for updates automatically every time you launch the software. However, if you keep browser tabs always open, then you should remember to restart the browser from time to time to trigger update checks.
Update Your Operating System
Keeping your operating system up-to-date is important as well, especially if it’s been some time since the last update.
If you have automatic updates turned on for Windows 10, then you don’t need to worry about this so much. But not all operating systems apply updates automatically so it’s worth checking if there are any available for your Operating System.
On macOS click the apple icon and select About This Mac which will open a tabbed window:
If a system update is available you’ll see a Software Update button. Click this to install the latest updates. You can also check for macOS updates via the App Store just like you would for any other app.
If you’re faced with a lengthy operating system update, you might want to just reboot your computer before running it as a quick workaround. This is much quicker than installing full operating system updates and could potentially solve the secure connection issue.
Temporarily Disable Antivirus and Firewall
It’s very important to have an antivirus and firewall software active on your system. These tools do a great job of protecting you from all sorts of online security issues.
As part of this protection, your antivirus software usually checks for issues with HTTPS connections to make sure nothing unexpected is happening. Sometimes, though, the software might incorrectly block a secure connection when it shouldn’t.
To check this isn’t the case, temporarily disable it and check your website again. If necessary, disable your firewall as well and check your website again.
Remember to always re-activate your antivirus software and firewall as soon as possible as you don’t want to leave your system unprotected.
Check Server Log for Error Messages
If you’ve reached this stage and still haven’t resolved the ERR_SSL_PROTOCOL_ERROR issue, things might be a bit more complicated than what we thought in the beginning.
To help identify general website issues, including connection errors, it can often help to check your server log and take a look at recent activity. This may well give more insight into what’s causing the issue.
If Everything Else Fails
If you still can’t find what’s causing the issue then it’s time to let us know. We’re here to help as always!
We’ll need to look deeper into what’s causing the issue so please contact support with as much relevant information as possible to get this issue resolved quickly.
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275 PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.