Содержание
- Vesta Control Panel — Forum
- Не работает SSL (ERR_SSL_PROTOCOL_ERROR) Topic is solved
- ERR_SSL_PROTOCOL_ERROR
- CentOS
- Required: idiots guide to SSL certificate install
- Required: idiots guide to SSL certificate install
- How to Fix the ERR_SSL_PROTOCOL_ERROR
- Check Out Our Video Guide to Fixing SSL Connection Errors
- Google Chrome
- Microsoft Edge
- Mozilla Firefox
- 8 Things to Do When Experiencing ERR_SSL_PROTOCOL_ERROR:
- What is a Secure Connection Anyway?
- Taking Stock of Your Site
- Solutions to ERR_SSL_PROTOCOL_ERROR
- Clear SSL State
- Verify SSL Certificate
- Deploy your application to Kinsta — Start with a $20 Credit now.
- 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
- Check Server Log for Error Messages
- If Everything Else Fails
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:
- 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.
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.
Источник
ERR_SSL_PROTOCOL_ERROR
5
Посты
2
Пользователи
0
Likes
11.3 Тыс.
Просмотры
(@begemot)
New Member
Присоединился: 5 лет назад
Столкнулся с проблемой. Есть конфиг
server {
listen 80;
listen [::]:80;
server_name mysite1.ru www.mysite1.ru;
return 301 https://$host$request_uri;
}
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;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
location ~ /.well-known {
allow all;
}
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;
}
location ~ /. {
deny all;
}
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;
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;
Как быть? Где я ошибся?
(@begemot)
New Member
Присоединился: 5 лет назад
(@begemot)
New Member
Присоединился: 5 лет назад
Только я его допилил немного, ибо с ним оценка B была.
(@zerox)
Prominent Member
Присоединился: 9 лет назад
А какая стала? Покажите итоговый конфиг. Я не уделял внимания рейтингу надежности https.
(@begemot)
New Member
Присоединился: 5 лет назад
Пожалуйста:
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;
location ~ /.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 ~ /. {
deny all;
}
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;
}
location ~ /. {
deny all;
}
}
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.
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.
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.
Приветствую, уважаемые форумчане! Проблема возникла довольно внезапно, всё что пришло в голову сам уже перепробовал, но знаний в этой области катастрофически не хватает, посему обращаюсь за помощью к вам.
На 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’m trying to configure Apache on my server to work with ssl, but everytime I visit my site, I get the following message in my browser:
SSL connection error.
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don’t have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.
The error message above seems to be native to Google Chrome. However, even though the messages are different, ssl for the site is not working on any browser.
Just some background on the situation: I am using Ubuntu 10.04 desktop edition
.
I installed apache
by installing zend server
(it installed apache automatically).
I then installed openssl
. Non-https pages work fine on the site.
I tried getting trial certificates from multiple certificate sites but nothing is working (same error).
I was previously hosting my site on another server on which ssl worked just fine. I also tried using the key and cert file from that server, but I got the same error.
The domain name and IP are still the same though. My SSLCertificateFile
and SSLCertificateKeyFile
are pointing to the correct directory and files.
I also do not have SSLVerifyClient enabled.
If anyone has any suggestions, it would be most appreciated.
asked Jul 20, 2010 at 3:01
2
I had the same problem as @User39604, and had to follow VARIOUS advices. Since he doesnt remember the precise path he followed, let me list my path:
-
check if you have SSL YES using
<?php echo phpinfo();?>
-
if necessary
A. enable ssl on apache
sudo a2enmod ssl
B. install openssl
sudo apt-get install openssl
C. check if port 443 is open
sudo netstat -lp
D. if necessary, change
/etc/apache2/ports.conf
, this worksNameVirtualHost *: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>
-
acquire a key and a certificate by
A. paying a Certificating Authority (Comodo, GoDaddy, Verisign) for a pair
B. generating your own* — see below (testing purposes ONLY)
-
change your configuration (in ubuntu12
/etc/apache2/httpd.conf
— default is an empty file) to include a proper<VirtualHost>
(replaceMYSITE.COM
as well as key and cert path/name to point to your certificate and key):<VirtualHost _default_:443> ServerName MYSITE.COM:443 SSLEngine on SSLCertificateKeyFile /etc/apache2/ssl/MYSITE.COM.key SSLCertificateFile /etc/apache2/ssl/MYSITE.COM.cert ServerAdmin MYWEBGUY@localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/errorSSL.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/accessSSL.log combined </VirtualHost>
while many other virtualhost configs wil be available in /etc/apache2/sites-enabled/
and in /etc/apache2/sites-available/
it was /etc/apache2/httpd.conf
that was CRUCIAL to solving all problems.
for further info:
http://wiki.vpslink.com/Enable_SSL_on_Apache2
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#selfcert
*generating your own certificate (self-signed) will result in a certificate whose authority the user’s browser will not recognize. therefore, the browser will scream bloody murder and the user will have to «understand the risks» a dozen times before the browser actually opens up the page. so, it only works for testing purposes. having said that, this is the HOW-TO:
- goto the apache folder (in ubuntu12
/etc/apache2/
) - create a folder like
ssl
(or anything that works for you, the name is not a system requirement) - goto chosen directory
/etc/apache2/ssl
- run
sudo openssl req -new -x509 -nodes -out MYSITE.COM.crt -keyout MYSITE.COM.key
- use
MYSITE.COM.crt
andMYSITE.COM.key
in your<VirtualHost>
tag
name format is NOT under a strict system requirement, must be the same as the file
— names like 212-MYSITE.COM.crt
, june2014-Godaddy-MYSITE.COM.crt
should work.
Andrew Quebe
2,2435 gold badges25 silver badges52 bronze badges
answered Dec 19, 2014 at 14:38
tony giltony gil
9,3686 gold badges76 silver badges98 bronze badges
7
I was getting the same error in chrome (and different one in Firefox, IE).
Also in error.log i was getting [error] [client cli.ent.ip.add] Invalid method in request x16x03
Following the instructions form this site I changed my configuration FROM:
<VirtualHost subdomain.domain.com:443>
ServerAdmin admin@domain.com
ServerName subdomain.domain.com
SSLEngine On
SSLCertificateFile conf/ssl/ssl.crt
SSLCertificateKeyFile conf/ssl/ssl.key
</VirtualHost>
TO:
<VirtualHost _default_:443>
ServerAdmin admin@domain.com
ServerName subdomain.domain.com
SSLEngine On
SSLCertificateFile conf/ssl/ssl.crt
SSLCertificateKeyFile conf/ssl/ssl.key
</VirtualHost>
Now it’s working fine
answered Apr 30, 2012 at 16:00
Alex OkrushkoAlex Okrushko
7,0246 gold badges44 silver badges63 bronze badges
3
Step to enable SSL correctly.
sudo a2enmod ssl
sudo apt-get install openssl
Configure the path of SSL certificates in your SSL config file (default-ssl.conf) that might be located in /etc/apache2/sites-available. I have stored certificates under /etc/apache2/ssl/
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/certificate.crt
SSLCertificateChainFile /etc/apache2/ssl/ca_bundle.crt
SSLCertificateKeyFile /etc/apache2/ssl/private.key
Enable SSL config file
sudo a2ensite default-ssl.conf
answered Jun 10, 2019 at 19:37
Syed ShibliSyed Shibli
9821 gold badge12 silver badges15 bronze badges
A common cause I wanted to suggest for this situation:
Sometimes a customer is running Skype, which is using port 443 without their realizing it. When they go to start Tomcat or Apache, it appears to start but cannot bind with port 443. This is the exact message that the user would receive in the browser. The fix is to stop what was running on port 443 and re-start the webserver so it can bind with port 443.
The customer can re-start Skype after starting the webserver, and Skype will detect that port 443 is in use and choose a different port to use.
answered May 30, 2012 at 21:22
#Make sure that you specify the port for both http and https ie.
NameVirtualHost:80
NameVirtualHost:443
#and
<VirtualHost *:80>
<VirtualHost *:443>
#mixing * and *:443 does not work it has to be *:80 and *:443
answered Sep 21, 2012 at 20:54
JeremyJeremy
711 silver badge3 bronze badges
3
I got this problem and the solution was a bit silly.
I am using Cloudflare which acts as a proxy to my website. In order to be able to login via SSH, I added an entry to my /etc/hosts
file so I didn’t need to remember my server’s IP address.
xxx.xx.xx.xxx example.com
So in my browser when I went to https://www.example.com, I was using the Cloudflare proxy, and when I went to to https://example.com I was going directly to the server. Because the Cloudflare setup doesn’t require you to add the intermediate certificates, I was seeing this security exception in my browser when I went to https://example.com, but https://www.example.com was working.
The solution: remove the entry from my laptop’s /etc/hosts
file.
If this isn’t your problem, I recommend using one of the many online SSL checker tools to try diagnose your problem.
I also recommend using ping to check the IP address being reported and check it against the IP address expected.
ping https://www.example.com/
Another very helpful SSL resource is the Mozilla SSL Configuration Generator. It can generate SSL configuration for you.
answered Oct 8, 2017 at 9:47
DagmarDagmar
2,73121 silver badges27 bronze badges
I didn’t know what I was doing when I started changing the Apache configuration. I picked up bits and pieces thought it was working until I ran into the same problem you encountered, specifically Chrome having this error.
What I did was comment out all the site-specific directives that are used to configure SSL verification, confirmed that Chrome let me in, reviewed the documentation before directive before re-enabling one, and restarted Apache. By carefully going through these you ought to be able to figure out which one(s) are causing your problem.
In my case, I went from this:
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRequireSSL On
to this
<Location /sessions>
SSLRequireSSL
SSLVerifyClient require
</Location>
As you can see I had a fair number of changes to get there.
answered Dec 3, 2010 at 20:59
Fitter ManFitter Man
6828 silver badges16 bronze badges
I had this error when I first followed instructions to set up the default apache2 ssl configuration, by putting a symlink for /etc/apache2/sites-available/default-ssl
in /etc/apache2/sites-enabled
. I then subsequently tried to add another NameVirtualHost on port 443 in another configuration file, and started getting this error.
I fixed it by deleting the /etc/apache2/sites-enabled/default-ssl
symlink, and then just having these lines in another config file (httpd.conf, which probably isn’t good form, but worked):
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on
SSLCertificateChainFile /etc/apache2/ssl/chain_file.crt
SSLCertificateFile /etc/apache2/ssl/site_certificate.crt
SSLCertificateKeyFile /etc/apache2/ssl/site_key.key
ServerName www.mywebsite.com
ServerAlias www.mywebsite.com
DocumentRoot /var/www/mywebsite_root/
</VirtualHost>
answered Oct 7, 2012 at 0:25
I encounter this problem, because I have <VirtualHost>
defined both in httpd.conf and httpd-ssl.conf.
in httpd.conf, it’s defined as
<VirtualHost localhost>
in httpd-ssl.conf, it’s defined as
<VirtualHost _default_:443>
The following change solved this problem, add :80 in httpd.conf
<VirtualHost localhost:80>
answered Apr 19, 2013 at 14:42
DanielDaniel
3914 silver badges8 bronze badges
This is what fixed it for me on Ubuntu.
- Enabled the module:
a2enmod ssl
- Moved all cert related files to a folder
/usr/local/ssl
and made it world readable:chmod -R +r /usr/local/ssl
- Changed
<VirtualHost *:80>
to<VirtualHost *:*>
in my virtual host. - Added
SSLEngine On
before all other SSL directives in my virtual host.
If you set a pass phrase on the cert, Apache should prompt you for it on restart.
answered Aug 4, 2014 at 13:49
ZnarkusZnarkus
23k22 gold badges78 silver badges108 bronze badges
1
Similar to other answers, this error can be experienced when there are no sites configured to use SSL.
I had the error when I upgraded from Debian Wheezy to Debian Jessie. The new version of Apache requires a site configuration file ending in .conf
. Because my configuration file didn’t, it was being ignored, and there were no others configured to serve SSL connections.
answered Jun 10, 2015 at 13:52
I encountered this issue, also due to misconfiguration. I was using tomcat and in the server.xml had specified my connector as such:
<Connector port="17443" SSLEnabled="true"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keyAlias="wrong" keystorePass="secret"
keystoreFile="/ssl/right.jks" />
When i fixed it thusly:
<Connector port="17443" SSLEnabled="true"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keyAlias="right" keystorePass="secret"
keystoreFile="/ssl/right.jks" />
It worked as expected. In other words, verify that you not only have the right keystore, but that you have specified the correct alias underneath it. Thanks for the invaluable hint user396404.
answered May 21, 2011 at 16:23
LucasLucas
13.7k9 gold badges71 silver badges120 bronze badges
1
It turns out that the SSL certificate was installed improperly. Re-installing it properly fixed the problem
answered Apr 30, 2012 at 3:01
user396404user396404
2,7497 gold badges30 silver badges42 bronze badges
3
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:
-
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
-
I copy both the files to /etc/pki/tls/private
-
I open mywebsite1.crs then copy and paste the code to Godaddy.
-
I generate the crt files and download them from Godaddy, upload to my server, and then move them to /etc/pki/tls/certs
-
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:
- I’ve read that you must enable ssl with a command called «a2enmod ssl» but that command does not exist for my server.
- There are no ssl error logs in /etc/httpd/logs.
- 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.
- 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.