Неправильный (первый / по умолчанию) SSL-сертификат обслуживается Apache 2.4 - веб-сервер с несколькими доменами Ubuntu 18.04

Предыстория: мы перенесли 2 старых веб-сервера на 2 новых, более надежных сервера - Ubuntu 17.04 и 18.04. Мы приобрели Thawte SSL-сертификаты для доменов, которые мы размещаем (около 20) для использования на 2 серверах. Каждый сервер имеет собственный статический IP-адрес.

Сертификаты были настроены в виде общего имени www.example.org и альтернативных имен www.example.org, example.org, www2.example.org

Сервер 17.04 содержит субдомены "www2". SSL-сертификаты были настроены, и все работает нормально, обеспечивая HTTPS и никаких несоответствий сертификатов

Я установил сервер 18.04, который содержит наш "www", и попытался отразить настройки. После некоторых проб и ошибок (забыв заголовкам a2enmod, синтаксическая ошибка vhost в файле.conf), я получил первый домен, который доставил https

Однако при настройке следующего домена.conf vhost браузеры с поддержкой SNI выдавали ошибку, что сайт использовал сертификат первого домена. Я гуглил и экспериментировал, проверял мой синтаксис и пути - я застрял.

Интересно, что когда я использую средства проверки SSL, они сообщают, что второй домен проходит, и он, кажется, сообщает о правильном владении доменом сертификатом. Но все браузеры, внутри сети и вне ее, сообщают об ошибке. Если я проигнорирую ошибку и продолжу, это приведет меня к 1-му домену.

Каждый домен имеет свой собственный файл.conf в /etc/apache2/sites-available. Я читал, где кто-то посоветовал поместить все виртуальные хосты в 1.conf - я попробовал тот же результат, но второй домен в то время не проходил SSL-тест.

Кажется, что мой 2-й домен возвращает сертификат 1-го домена, и из того, что я прочитал, можно ожидать, что он сделает это для всех остальных. Эти сайты живы, и я не могу (не должен) отключать их во время тестирования. Я использую наш наименее посещаемый сайт для второго примера домена. Кто-то предположил, что это может быть проблема с кэшированием, и проблема решилась много часов спустя. Я не могу помочь, но думаю, что пропустил некоторые настройки сервера, которые используют SNI, но Apache 2.4 якобы поставляет SNI из коробки

из ports.conf

    Listen 80

    <IfModule ssl_module>
            Listen 443
    </IfModule>

    <IfModule mod_gnutls.c>
            Listen 443
    </IfModule>

из example.conf

    <VirtualHost *:80>
            ServerName www.example.org
            ServerAlias example.org www4.example.org
            ServerAdmin webmaster@xxxxxxxx.com

            Redirect 301 "/" "https://www.example.org/"
    </VirtualHost>

    <IfModule ssl_module>

        SetEnvIf HTTPS https HTTPS=on
        Header always set Strict-Transport-Security "max-age=63072000" env=HTTPS
        Header always set Content-Security-Policy: upgrade-insecure-requests env=HTTPS
        Header always set X-XSS-Protection: "1; mode=block"
        Header always set X-Frame-Options: sameorigin
        Header always set X-Content-Type-Options: nosniff
        Header always set X-Permitted-Cross-Domain-Policies: "master-only"

    <VirtualHost *:443>
            ServerName www.example.org
            DocumentRoot /var/www/example/

            ServerAdmin webmaster@xxxxxxxx.com
            SSLEngine on
            SSLCertificateFile "/etc/apache2/ssl/crt/www.example.org.crt"
            SSLCertificateChainFile "/etc/apache2/ssl/crt/IntermediateCA.example.crt"
            SSLCertificateKeyFile "/etc/apache2/ssl/www.example.org.key"

            DirectoryIndex index.html index.htm index.php

            <FilesMatch "^wp-login\.php$|^wp-admin/.*">
                    AuthName "Login Login"
                    AuthType Basic
                    AuthUserFile /etc/apache2/.htpasswd
                    Require valid-user
            </FilesMatch>

    </VirtualHost>

    </IfModule>

из otherdomain.conf

    <VirtualHost *:80>
            ServerName www.otherdomain.org
            ServerAlias otherdomain.org www4.otherdomain.org
            ServerAdmin webmaster@xxxxxxxx.com

           Redirect 301 "/" "https://www.otherdomain.org/"

     </VirtualHost>

     <IfModule ssl_module>

         SetEnvIf HTTPS https HTTPS=on
         Header always set Strict-Transport-Security "max-age=63072000" env=HTTPS
         Header always set Content-Security-Policy: upgrade-insecure-requests env=HTTPS
         Header always set X-XSS-Protection: "1; mode=block"
         Header always set X-Frame-Options: sameorigin
         Header always set X-Content-Type-Options: nosniff
         Header always set X-Permitted-Cross-Domain-Policies: "master-only"

      <VirtualHost *:443>
             ServerName www.otherdomain.org
             DocumentRoot /var/www/otherdomain/

           ServerAdmin webmaster@xxxxxxxx.com
           SSLEngine on
           SSLCertificateFile "/etc/apache2/ssl/crt/www.otherdomain.org.crt"
           SSLCertificateChainFile "/etc/apache2/ssl/crt/IntermediateCA.otherdomain.crt"
           SSLCertificateKeyFile "/etc/apache2/ssl/www.otherdomain.org.key"

            DirectoryIndex index.html index.htm index.php

            <FilesMatch "^wp-login\.php$|^wp-admin/.*">
                    AuthName "Login Login"
                    AuthType Basic
                    AuthUserFile /etc/apache2/.htpasswd
                    Require valid-user
            </FilesMatch>

    </VirtualHost>

    </IfModule>

Возможно, важно, что сайты и серверы www - это сайты WordPress. Субдомен "www4", который я использовал для целей тестирования при переносе указанных сайтов WordPress из среды PHP 5.2 в 7. Как только сайты отображались корректно, я указал DNS(свободный от Cloudflare) для www со статического IP-адреса старого сервера на статический IP-адрес нового (Ubuntu18.04) сервера.

Вещи, которые я пробовал:
добавление подстановочного знака * в ports.conf
перезапуск службы sudo apache2
служба sudo apache2 остановка / запуск
комментируя редирект у меня в порте 80 Virtualhost
проверка путей сертификата
жду 6+ часов

Занимаясь этим почти неделю, я исчерпал все свои поисковые комбинации, признав поражение и попросив о помощи. Заранее спасибо.

2 ответа

Я закончил тем, что выяснил это некоторое время назад, работая с порядком вещей. Что в итоге сработало для всех файлов.conf для всех наших сайтов:

    <VirtualHost *:80>
            ServerName www.otherdomain.org
            ServerAlias www4.otherdomain.org otherdomain.org
            ServerAdmin webmaster@otherdomain.org
            DocumentRoot /var/www/otherdomain/
            Redirect 301 "/" "https://www.otherdomain.org/"
    </VirtualHost>



   <IfModule ssl_module>
       SetEnvIf HTTPS https HTTPS=on
       Header always set Strict-Transport-Security "max-age=63072000" env=HTTPS
       Header always set Content-Security-Policy: upgrade-insecure-requests env=HTTPS
       Header always set X-XSS-Protection: "1; mode=block"
       Header always set X-Frame-Options: sameorigin
       Header always set X-Content-Type-Options: nosniff
       Header always set X-Permitted-Cross-Domain-Policies: "master-only"

    <VirtualHost *:443>
            ServerName www.otherdomain.org
            ServerAlias otherdomain.org
            DocumentRoot /var/www/otherdomain/

            ServerAdmin webmaster@societyhq.com
            SSLEngine on
            SSLCertificateFile "/etc/apache2/ssl/crt/www.otherdomain.org.crt"
            SSLCertificateChainFile "/etc/apache2/ssl/crt/IntermediateCA.otherdomain.crt"
            SSLCertificateKeyFile "/etc/apache2/ssl/www.otherdomain.org.key"

            DirectoryIndex index.html index.htm index.php


    <FilesMatch "^wp-login\.php$|^wp-admin/.*">
            AuthName "Login Login"
            AuthType Basic
            AuthUserFile /etc/apache2/.htpasswd
            Require valid-user
    </FilesMatch>

    </VirtualHost>

    </IfModule>

В чем конкретно виноват мой последующий файл conf с использованием сертификатов с первого раза, я не знаю.

На сегодняшний день, в 2023 году, все еще существует ошибка неправильного сертификата, которая подробно описана в https://blog.apnic.net/2020/04/07/the-wrong-certificate-apache-lets-encrypt-and-openssl/ с Причина в неправильном поведении библиотеки openssl по умолчанию, не зависящем от предполагаемого имени хоста для сайта.

Другие вопросы по тегам