Apache SSL: сертификат сервера не содержит идентификатора, который соответствует имени сервера

21

Я пытаюсь настроить SSL на своем веб-сервере apache2, но кажется, что он вообще не работает.

Я следовал руководству по созданию файлов сертификатов с openssl и /etc/apache2/sites-available/default-ssl.confправильно настроил их.

Каждый раз, когда я пытаюсь открыть свой сайт с помощью https, мой браузер отказывается подключаться из-за проблем с безопасностью. Там написано, что я неправильно настроил свой сайт.

По моему /var/log/apache2/error.logя получаю предупреждения, в которых говорится, что мой сертификат сервера не содержит идентификатор, который соответствует имени сервера.

[Mon Apr 10 11:03:24.041813 2017] [mpm_prefork:notice] [pid 1222] AH00169: caught SIGTERM, shutting down
[Mon Apr 10 11:03:30.566578 2017] [ssl:warn] [pid 661] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.579088 2017] [ssl:warn] [pid 1194] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Mon Apr 10 11:03:31.592958 2017] [mpm_prefork:notice] [pid 1194] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2k configured -- resuming normal operations
[Mon Apr 10 11:03:31.593136 2017] [core:notice] [pid 1194] AH00094: Command line: '/usr/sbin/apache2'

У вас есть идеи, как это решить? Спасибо в отношении!

pixelmusic
источник
Вы использовали Apache 2.2 или 2.4? Я обновил с 2.2 до 2.4 и получаю эту ошибку. В моем случае это не публичный сервер, а внутренний, поэтому я думаю, что самоподписанный сертификат подойдет.
svhyd
Я использовал Apache 2.2 на своем общедоступном сервере (Debian 8), когда я получил эту ошибку. После переключения на Let's Encript ошибка исчезла, так что я думаю, что именно самозаверяющий сертификат вызвал ошибку.
pixelmusic

Ответы:

7

Хорошо, я заметил, что этот пост просматривается довольно часто в последнее время, и поэтому многие люди сталкиваются с той же проблемой, что и я. Если это так, то это может помочь вам.

Я следовал простому пошаговому руководству, чтобы создать SSL-сертификацию для моего веб-сервера. Как и во многих других уроках, результатом урока, которым я следовал, был самозаверяющий сертификат с использованием OpenSSL. Да, самоподписанный , это была проблема. Браузер не может доверять серверу из-за его сертификата, который сам подписан. Ну, я бы тоже не стал ...

Сертификат должен быть подписан внешним заслуживающим доверия центром сертификации (ЦС). Поэтому я наткнулся на Let's Encrypt, который выполняет всю работу за вас, и его еще проще настроить, а самое лучшее: он абсолютно бесплатный.

Установка

1) Удалите ваши старые файлы сертификата ssl, которые вы создали с помощью OpenSSL

2) Откройте backports для получения клиента certbot в Debian. Вы должны знать, что это откроет дыру для незаконченного программного обеспечения! Устанавливайте пакеты только тогда, когда вы знаете, что делаете.

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

3) Обновите систему Linux

sudo apt-get update

4) Установите certbot

sudo apt-get install python-certbot-apache -t jessie-backports

5) Настройте apache ServerName и ServerAlias

sudo nano /etc/apache2/sites-available/000-default.conf

6) Редактировать конфигурационный файл apache

<VirtualHost *:80>
    . . .
    ServerName example.com
    ServerAlias www.example.com
    . . .
</VirtualHost>

7) Проверьте правильность синтаксиса.

sudo apache2ctl configtest

8) Если файл конфигурации выглядит нормально, перезапустите сервер Apache

sudo systemctl restart apache2

9) Установите сертификат с помощью certbot и следуйте инструкциям на экране.

sudo certbot --apache

обновление

Все сертификаты Let's Encrypt действительны в течение 3 месяцев. Чтобы обновить, вы можете запустить вручную

sudo certbot renew

Или автоматизировать этот сервис как работу cron

sudo crontab -e

и введите следующую строку, чтобы вызывать обновление каждый понедельник в 2:30.

. . .
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

Вы можете следовать более подробному руководству здесь: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8

pixelmusic
источник
Это не может быть использовано для localhost (виртуальной машины в локальной сети), я имею в виду, вам нужно купить домен, чтобы использовать шифрование, верно?
lewis4u
1
да, ваш веб-сервер должен быть доступен через зарегистрированный домен, чтобы шифрование работало.
pixelmusic
2

Если вы не видите никаких других ошибок SSL, и если вы попытались установить «Отладка LogLevel» в файле httpd.conf, это сообщение об ошибке также может означать, что в файле httpd.conf отсутствует «Listen 443».

BenjaminBrink
источник
я совершенно забываю, чтобы Apache слушал 443, он слушал только 80, спасибо
Robert
1

Это не ошибки - это предупреждения. Вполне возможно запустить mod_ssl с сертификатом, который не соответствует определенным именам серверов, если у вас определен хост ssl по умолчанию, а общее имя в сертификате совпадает с именем хоста, используемым клиентами для подключения.

Последнее не похоже на правду в вашем случае. Как говорит Джейкоб, вам нужно указать правильное имя хоста в качестве общего имени (или псевдонима) при создании CSR .

Чтобы увидеть, какие имена в настоящее время указаны в сертификате:

openssl s_client -showcerts -connect ${HOSTNAME}:443

Если на машине установлено несколько сертификатов, которые обслуживаются на одном IP-адресе, то:

openssl s_client -showcerts -connect ${HOSTIP}:443 -servername ${HOSTNAME}

(где значения $ {...} являются заполнителями, вы должны заменить их соответствующими значениями).

symcbean
источник
(1) вы должны поместить имя сервера в CommonName в CSR, но то, действительно ли оно необходимо (проверяет и / или копирует ли он CA), зависит от CA (2) openssl s_clientпоказывает субъект и эмитента для листового сертификата, который является единственным вам нужно здесь, без -showcerts, но для реальных сертификатов CA, начиная примерно с 2010 года (и сертификатов DIY от компетентных людей), на что вам нужно обратить внимание, это не предмет, а расширение SubjectAltName (SAN), а для этого вам нужноopenssl s_client -connect h:p [-servername h] | openssl x509 -noout -text
dave_thompson_085
Обратите внимание, что с середины 2018 года вам необходимо также указывать DNS-имя в альтернативных именах субъектов, если вы хотите, чтобы ваш сертификат корректно проверялся в современных браузерах.
Symcbean
Я не знаю каких-либо изменений в 2018 году; Chrome требует SAN (для DNS или IP, хотя последний редко используется) с начала 2017 года, а Firefox и IE (который я до сих пор считаю современным) не требуют его сегодня - хотя, как я ранее говорил, публичные CA предоставили это намного дольше.
dave_thompson_085
0

Я столкнулся с этой проблемой недавно, когда истек срок действия моего самоподписанного сертификата. Я гуглил и просто скопировал команду для создания нового сертификата с одного веб-сайта.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/apache2/ssl/apache.crt

В моем конфигурационном файле apache: /etc/apache2/sites-available/default-ssl.conf. Файл сертификата и файл ключа относятся к следующему имени файла.

    SSLCertificateFile  /etc/apache2/ssl/apache.crt
    SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Следовательно, ошибка, замеченная здесь в моем случае, была легче исправить, просто предоставив правильное местоположение файла ключа сертификата при создании сертификата ssl.

Итак, вот команда, которую я должен был использовать и набрать правильно.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Bhoom Suktitipat
источник
0

В моем случае я решил эту проблему с помощью замены в моем конфигурационном файле apache ssl для каждого соответствующего домена:

ServerName mydomain.com
ServerAlias www.mydomain.com

по :

ServerName www.mydomain.com
ServerAlias mydomain.com

Потому что мой сертификат для "www.mydomain.com", а не для "mydomain.com"

полный файл apache:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin noreply@mydomain.com
        ServerName www.mydomain.com
        ServerAlias mydomain.com
    DocumentRoot /home/mydomain.com/public_html
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|ico|png)$ \ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ \no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    <Directory />
        Options +FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /home/mydomain.com/public_html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride All
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>


ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel warn
SSLCertificateFile /etc/letsencrypt/live/www.mydomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mydomain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
user2267379
источник
0

Нам пришлось добавить ServerName и ServerAlias ​​в файл default-ssl, а не только в файл conf для конкретного домена.
Это избавило нас от досадной ошибки.

Гай Гракх
источник