Centos err ssl protocol error

Vesta Control Panel — Forum

Не работает SSL (ERR_SSL_PROTOCOL_ERROR) Topic is solved

Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by 1RONMAN » Sat Mar 16, 2019 6:58 am

Приветствую, уважаемые форумчане! Проблема возникла довольно внезапно, всё что пришло в голову сам уже перепробовал, но знаний в этой области катастрофически не хватает, посему обращаюсь за помощью к вам.

На 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. куда копать совсем не понимаю, дайте пожалуйста какое-нибудь направление! 🙁

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by 1RONMAN » Sat Mar 16, 2019 10:17 am

Судя по всему проблема была связана с тем что у меня было 2 домена на 1 IP и на обоих был включен SSL. Не знаю как это связано но отключение SSL на первом домене мгновенно решило проблему со вторым — SSL заработал, сайт стал доступен. Вот так.

Хотелось бы услышать комментарии профи по этому поводу.)

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by DESSAR_SEGA » Sun May 26, 2019 10:02 pm

Судя по всему проблема была связана с тем что у меня было 2 домена на 1 IP и на обоих был включен SSL. Не знаю как это связано но отключение SSL на первом домене мгновенно решило проблему со вторым — SSL заработал, сайт стал доступен. Вот так.

Хотелось бы услышать комментарии профи по этому поводу.)

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by mr.flash » Thu May 30, 2019 2:51 am

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by mr.flash » Thu May 30, 2019 3:02 am

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by 1RONMAN » Wed Oct 23, 2019 9:07 am

Немного займусь некропостингом: после этой проблемы добавил для каждого домена свой IP, после этого всё стало работать нормально.

Однако тут стоит упомянуть что на тот момент у меня в принципе был достаточно криво настроен сервер, так что я бы не стал винить в этом Vesta. Возможно причина вообще в другом, а в чём я не знаю т.к. было принято решение тупо переустановить сервер уже с новым дистрибутивом (но это совсем другая история).

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by skurudo » Wed Oct 23, 2019 9:41 am

Re: Не работает SSL (ERR_SSL_PROTOCOL_ERROR)

Post by 1RONMAN » Wed Oct 23, 2019 9:55 am

Источник

ERR_SSL_PROTOCOL_ERROR

11.3 Тыс. Просмотры

Столкнулся с проблемой. Есть конфиг

server <
listen 443 http2 ssl;
server_name www.mysite1.ru;
ssl_certificate /etc/letsencrypt/live/mysite1.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite1.ru/privkey.pem;
return 301 https://mysite1.ru $request_uri;
>

server <
listen 443 http2 ssl;
server_name mysite1.ru;
ssl_certificate /etc/letsencrypt/live/mysite1.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite1.ru/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers «EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH»;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 77.88.8.8 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security «max-age=63072000; includeSubdomains»;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;

root /home/user/web/mysite1.ru/public_html;
index index.php index.html index.htm;

location / <
try_files $uri $uri/ /index.php?$uri&$args;
index index.php index.html;
>

location /internal_data/ <
internal;
>

location /library/ <
internal;
>

.php$ <
try_files $uri =404;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_read_timeout 600;
include fastcgi_params;
fastcgi_cache_valid 200 60m;
>
error_page 404 /404error.html;
location = /404error.html <
root /usr/share/nginx/html;
internal;
>
error_page 403 /403error.html;
location = /403error.html <
root /usr/share/nginx/html;
internal;
>
>

Но из-за него лезет ошибка из названия темы.

Если удалить блок:

server <
listen 443 http2 ssl;
server_name www.mysite1.ru;
ssl_certificate /etc/letsencrypt/live/mysite1.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite1.ru/privkey.pem;
return 301 https://mysite1.ru $request_uri;
>

то форум начинает работать, но, соответственно, пропадает редирект с www на без www по https.

Путем комментирования выяснил, что дает ошибку на эту строку: listen 443 http2 ssl;

Как быть? Где я ошибся?

Только я его допилил немного, ибо с ним оценка B была.

А какая стала? Покажите итоговый конфиг. Я не уделял внимания рейтингу надежности https.

server <
listen 80;
server_name www.mysite1.ru;
rewrite ^ https://mysite1.ru $request_uri? permanent;
>

server <
listen 443 ssl http2;
server_name mysite1.ru;
ssl_certificate /etc/letsencrypt/live/mysite1.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite1.ru/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ‘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’;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 77.88.8.8 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security «max-age=63072000; includeSubdomains»;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

root /home/username/web/mysite1.ru/public_html;
index index.php index.html index.htm;

/.well-known <
allow all;
>
location / <
try_files $uri $uri/ /index.php?$uri&$args;
index index.php index.html;
>
location /internal_data/ <
internal;
>
location /library/ <
internal;
>
location

.php$ <
try_files $uri =404;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_read_timeout 600;
include fastcgi_params;
>

server <
listen 443 ssl http2;
server_name www.mysite1.ru;
ssl_certificate /etc/letsencrypt/live/mysite1.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite1.ru/privkey.pem;
rewrite ^ https://mysite1.ru $request_uri? permanent;
>

Я удалил ваши локейшены, прописал свои — они для работы ЧПУ на моем форуме нужны. Но, самое главное, пересобрал второй блок server. С таким получил A+ на ssllabs.

Источник

CentOS

The Community ENTerprise Operating System

Required: idiots guide to SSL certificate install

Required: idiots guide to SSL certificate install

Post by browningit » 2016/09/06 14:11:36

I’ve been arguing with some of the simpler things in linux. I can outline all the tutorials and links that I have slowly figured out while configuring my server; but I will try to keep this to just the gritty details of my SSL adventures in the last few hours. My set up:

Centos 7, apache 2.4.6 (?), GoDaddy SSL certificate. Server single purpose: Run Owncloud app. One domain only.

I have tried the following links and methods to set up the certificate, and get stuck at the same spot each time:

And a few others, but I am sure you get the point. I don’t need vhosts (I think, if I am wrong, kick me) since this server will be a single domain forever. I’ve successfully generated the key file and sent the CSR to Godaddy. Verified it, downloaded the chain file and my cert file. I place those files into:

I then edit ssl.conf to reflect the names of the files in that location, and I verify that the localhost.key is pointing to /etc/pki/tls/private/?.key. I noted the second link above said to comment out some lines and add some data in. Still ended up with this annoying result:

When I restart httpd at the end of the process, it just whines that it can’t restart the service.

job for httpd.service failed because the control process exited with error code.
see ‘systemctl status httpd.service’ and ‘journalctl -xn’ for details.

Why do I say idiots guide? I have to google simple things like ‘how to undo changes in vi’ etc. I’m clearly missing something simple. Anything that I have to type and in a certain order; or a line to edit will help me greatly.

Thanks so much in advance, beer to the one who gets me through this (promise, not a bait and switch!).

Источник

How to Fix the ERR_SSL_PROTOCOL_ERROR

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.

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.

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.

ERR_SSL_PROTOCOL_ERROR in Microsoft Edge

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

ERR_SSL_PROTOCOL_ERROR in Mozilla Firefox

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:

1. Clear SSL State.
2. Verify SSL Certificate (DNS settings haven’t fully propagated yet).
3. Check the System Time and Date.
4. Clear Browser Cache and Cookies.
5. Disable Browser Extensions.
6. Update Browsers to Latest Version.
7. Update Your Operating System.
8. 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.

Secure connection

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.

Deploy your application to Kinsta — Start with a $20 Credit now.

Run your Node.js, Python, Go, PHP, Ruby, Java, and Scala apps, (or almost anything else if you use your own custom Dockerfiles), in three, easy steps!

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.

SSL certificate properly installed

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.

SSL Server Test

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:

SSL Report Qualys

You can find more in-depth information on how to check your SSL certificate is working properly here.

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.

Date and time preferences in Windows 10

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.

Tired of dealing with security issues with your host? At Kinsta, we provide world-class security support, continuous monitoring for uptime, and hardware firewalls. Check out our hosting plans

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.

Chrome extensions window

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:

About this Mac

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.

Server log

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.

Источник

I tested with my new test server www.koepiste.fi/scyllaTest

Vanilla CentOS 7.5.1804, yum update, disabled SELinux, CSF, certbot, NodeJS 10.5.0.

Script running with pm2.

Aaaand same error on browser:
Error during WebSocket handshake: net::ERR_SSL_PROTOCOL_ERROR

server.js

const ClusterWS = require('clusterws')
const clusterws = new ClusterWS({
    worker: Worker,
    tlsOptions: {
        key : fs.readFileSync('/etc/letsencrypt/live/koepiste.fi/privkey.pem'),
        cert: fs.readFileSync('/etc/letsencrypt/live/koepiste.fi/cert.pem'),
        ca  : fs.readFileSync('/etc/letsencrypt/live/koepiste.fi/chain.pem'),
    }
})
function Worker() {
    let server = this.server, wss = this.wss
    server.on('request', app)
    wss.on('connection', socket => {
        // CLIENT IS ALWAYS CONNECTED, but on client side it gives that handshake error..
        console.log('CLIENT CONNECTED');
    })
}

Browser code ( just the socket part )

let socket = new ClusterWS({ url: 'wss://www.koepiste.fi/scyllaTest' })
socket.on('error',()=>console.log)
socket.on('connect',()=>{
    console.log('ClusterWS connected')
})

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.

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.

Приветствую, уважаемые форумчане! Проблема возникла довольно внезапно, всё что пришло в голову сам уже перепробовал, но знаний в этой области катастрофически не хватает, посему обращаюсь за помощью к вам.

На 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:

Кстати 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’ve never set up an SSL on Linux before, but have a general idea of how it works. Server specs below if it helps:

Server: CentOS Linux 6
Workstation: Windows 7

So, I have 4 domains all of which share a single Magento installation and IP address. Assume one of my domains is «mywebsite1.com» I am trying to enable SSL just for this one domain for now, but I am running into errors. What am I doing wrong? Here’s my work flow:

1. I purchased an SSL from Godaddy then generated the csr and key with the command given by them:

   openssl req -new -newkey rsa:2048 -nodes -keyout mywebsite1.key -out mywebsite1.csr

2. I copy both the files to /etc/pki/tls/private

3. I open mywebsite1.crs then copy and paste the code to Godaddy.

4. I generate the crt files and download them from Godaddy, upload to my server, and then move them to /etc/pki/tls/certs

5. a. 1st try, I opened /etc/httpd/conf.d/ssl.conf and updated the
   default VirtualHost block’s SSLCertificate File, KeyFile, and ChainFile values to point to the correct locations.

   b. 2nd try, following
   http://dev.antoinesolutions.com/apache-server/mod_ssl I modified
   ssl.conf and added this directive:

   NameVirtualHost *:443

   c. Then I removed the entire default VirtualHost block (which was
   quite lengthy).

   Last attempt, I added the following to the modified ssl.conf from


<VirtualHost *:443>

    SSLEngine on

    SSLCertificateFile /etc/pki/tls/certs/mywebsite1.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/mywebsite1.key
    SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle.crt
    DocumentRoot /var/www/html
    ServerName mywebsite1.com
</VirtualHost>

6.. I restart Apache

7.. I then go to https://mywebsite1.com only to find errors that prevent me from viewing the site in various browsers.

Browser: Firefox

SSL received a record with an unknown content type.

(Error code: ssl_error_rx_unknown_record_type)

Browser: Chrome

Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Browser: IE …takes me to Google…

httpd.conf:

NameVirtualHost 12.34.567.89

<VirtualHost 12.34.567.89>
    DocumentRoot  /var/www/html
    ServerName website1.com
</VirtualHost>

<VirtualHost 12.34.567.89>
    DocumentRoot  /var/www/html
    ServerName website2.com
</VirtualHost>

<VirtualHost 12.34.567.89>
    DocumentRoot  /var/www/html
    ServerName website3.com
</VirtualHost>

<VirtualHost 12.34.567.90:80>
    DocumentRoot /var/www/html
    ServerName website4.com
</VirtualHost>

Notes:

1. I’ve read that you must enable ssl with a command called «a2enmod ssl» but that command does not exist for my server.
2. There are no ssl error logs in /etc/httpd/logs.
3. As per Godaddy, I was instructed to name the key «mywebsite1» without the extension. However, they give me a crt with the extension, which is odd.
4. This is only development phase and this change will need to be quickly reproduced with a new SSL and different domains once we launch the production server.

I’ve tried all of the steps 3 times (see 5a-5c), but still no luck in getting the SSL to work for 1 of my domains. How can I get SSL to work?

UPDATE: apachectl -S

12.34.567.90:80 mywebsite4.com (/etc/httpd/conf/httpd.conf:1021)
12.34.567.89:* is a NameVirtualHost
default server mywebsite3.com (/etc/httpd/conf/httpd.conf:1016)
port * namevhost mywebsite3.com (/etc/httpd/conf/httpd.conf:1016)
port * namevhost mywebsite1.com (/etc/httpd/conf/httpd.conf:1026)
port * namevhost mywebsite2.com (/etc/httpd/conf/httpd.conf:1031)
port * namevhost mywebsite5.com (/etc/httpd/conf/httpd.conf:1036)
wildcard NameVirtualHosts and _default_ servers:
*:443 is a NameVirtualHost
default server mywebsite1.com (/etc/httpd/conf.d/ssl.conf:77)
port 443 namevhost mywebsite1.com (/etc/httpd/conf.d/ssl.conf:77)
Syntax OK

UPDATE: Got it working..but..

I managed to get the SSL running by changing the vhost to just point to mywebsite1 instead of *:443

<VirtualHost mywebsite1.com>
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/mywebsite1.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/mywebsite1.key
    #SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle.crt
    DocumentRoot /var/www/html
    ServerName mywebsite1.com
    ErrorLog logs/ssl_error_log
    TransferLog logs/ssl_access_log
    LogLevel warn
</VirtualHost>

This pulls up the SSL, however… the HTTP protocol returns a «Bad Request»

This change seems to be affecting the non-ssl viewing of the site. I can’t specify the port because restarting apache will give me an error that ports and non-ports can’t be mixed.

UPDATE

Fixed with the suggestion by Michael Hampton. Thanks guys.