Назад | Перейти на главную страницу

Ошибка SSL 107 - Конфигурация SSL Apache2

Я пытаюсь настроить новый веб-сервер для размещения веб-сайта / приложения php. Весь веб-трафик на этот сервер должен проходить через https. Я прочитал множество руководств, а также документы и вики Apache о том, как это настроить. Я также недавно опубликовано в SF по поводу проблемы, которую я тестировал фиктивную настройку этого на локальном компьютере (я упоминаю это только для того, чтобы указать, что я уверен, что не повторяю ту же ошибку).

Сервер работает под управлением 64-битной Ubuntu 12.04 с Apache2 v2.2.22, и в настоящее время требуется только для размещения этого одного веб-сайта / приложения php.

Моя проблема в том, что после настройки (получение сертификата из центра сертификации, включение mod_ssl, редактирование конфигураций виртуального хоста, настройка перенаправления https для HTTP-трафика, перезапуск apache и т. Д.), Когда я перехожу на свой сервер в моем браузере (работает Chromium в Linux Mint 14) Я просто получаю ошибку SSL 107:

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.

Вот вся информация, которую я могу собрать о своей конфигурации и об ошибке:

Мой файл ports.conf:

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    NameVirtualHost *:443
    Listen 443
</IfModule>

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

Я добавил строку NameVirtualHost *: 443 из-за эта почта, но я не знаю, делает ли он что-нибудь (как следует из комментария, он соответствует в конфигурации vh, см. ниже)

Вот файл конфигурации виртуального хоста для сайта (хранится в sites-available и активируется с помощью команды a2ensite)

<VirtualHost *:80>
        ServerAdmin webmaster@my-app.com
    ServerName login.my-app.com     
    Redirect permanent / https://login.my-app.com
</VirtualHost>


<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin webmaster@my-app.com


    #DocumentRoot /var/www/login.my-app.com
    ServerName login.my-app.com

    #Do these really do anything?
    #Alias /login.my-app.com /var/www/login.my-app.com
    #UserDir disabled root  

    <Directory />
        Options FollowSymLinks
        AllowOverride None
        Order Deny,Allow
            Deny from all
        #SSLRequireSSL
    </Directory>

    <Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        #SSLRequireSSL
    </Directory>


    <Directory /var/www/login.my-app.com>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        SSLRequireSSL
        </Directory>


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

    ErrorLog ${APACHE_LOG_DIR}/login.my-app.com.error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

    #   SSL Engine Switch:
    #   Enable/Disable SSL for this virtual host.
    SSLEngine on


    #   A self-signed (snakeoil) certificate can be created by installing
    #   the ssl-cert package. See
    #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
    #   If both key and certificate are stored in the same file, only the
    #   SSLCertificateFile directive is needed.
    #SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
    #SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    SSLCertificateFile    /etc/ssl/certs/my-app.com.crt
        SSLCertificateKeyFile /etc/ssl/private/my-app.com.key

    #   Server Certificate Chain:
    #   Point SSLCertificateChainFile at a file containing the
    #   concatenation of PEM encoded CA certificates which form the
    #   certificate chain for the server certificate. Alternatively
    #   the referenced file can be the same as SSLCertificateFile
    #   when the CA certificates are directly appended to the server
    #   certificate for convinience.
    #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
    # not sure if this one is used if Certificate Authority (CA) below is used?
    #SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

    #   Certificate Authority (CA):
    #   Set the CA certificate verification path where to find CA
    #   certificates for client authentication or alternatively one
    #   huge file containing all of them (file must be PEM encoded)
    #   Note: Inside SSLCACertificatePath you need hash symlinks
    #         to point to the certificate files. Use the provided
    #         Makefile to update the hash symlinks after changes.
    #SSLCACertificatePath /etc/ssl/certs/
    #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
    SSLCACertificateFile /etc/ssl/certs/intermediate.crt

    #   Certificate Revocation Lists (CRL):
    #   Set the CA revocation path where to find CA CRLs for client
    #   authentication or alternatively one huge file containing all
    #   of them (file must be PEM encoded)
    #   Note: Inside SSLCARevocationPath you need hash symlinks
    #         to point to the certificate files. Use the provided
    #         Makefile to update the hash symlinks after changes.
    #SSLCARevocationPath /etc/apache2/ssl.crl/
    #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

    #   Client Authentication (Type):
    #   Client certificate verification type and depth.  Types are
    #   none, optional, require and optional_no_ca.  Depth is a
    #   number which specifies how deeply to verify the certificate
    #   issuer chain before deciding the certificate is not valid.
    #SSLVerifyClient require
    #SSLVerifyDepth  10

    #   Access Control:
    #   With SSLRequire you can do per-directory access control based
    #   on arbitrary complex boolean expressions containing server
    #   variable checks and other lookup directives.  The syntax is a
    #   mixture between C and Perl.  See the mod_ssl documentation
    #   for more details.
    #<Location />
    #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
    #            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
    #            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
    #            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
    #            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
    #           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
    #</Location>

    #   SSL Engine Options:
    #   Set various options for the SSL engine.
    #   o FakeBasicAuth:
    #     Translate the client X.509 into a Basic Authorisation.  This means that
    #     the standard Auth/DBMAuth methods can be used for access control.  The
    #     user name is the `one line' version of the client's X.509 certificate.
    #     Note that no password is obtained from the user. Every entry in the user
    #     file needs this password: `xxj31ZMTZzkVA'.
    #   o ExportCertData:
    #     This exports two additional environment variables: SSL_CLIENT_CERT and
    #     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
    #     server (always existing) and the client (only existing when client
    #     authentication is used). This can be used to import the certificates
    #     into CGI scripts.
    #   o StdEnvVars:
    #     This exports the standard SSL/TLS related `SSL_*' environment variables.
    #     Per default this exportation is switched off for performance reasons,
    #     because the extraction step is an expensive operation and is usually
    #     useless for serving static content. So one usually enables the
    #     exportation for CGI and SSI requests only.
    #   o StrictRequire:
    #     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
    #     under a "Satisfy any" situation, i.e. when it applies access is denied
    #     and no other module can change it.
    #   o OptRenegotiate:
    #     This enables optimized SSL connection renegotiation handling when SSL
    #     directives are used in per-directory context.
    #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
        SSLOptions +StdEnvVars
    </Directory>

    #   SSL Protocol Adjustments:
    #   The safe and default but still SSL/TLS standard compliant shutdown
    #   approach is that mod_ssl sends the close notify alert but doesn't wait for
    #   the close notify alert from client. When you need a different shutdown
    #   approach you can use one of the following variables:
    #   o ssl-unclean-shutdown:
    #     This forces an unclean shutdown when the connection is closed, i.e. no
    #     SSL close notify alert is send or allowed to received.  This violates
    #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
    #     this when you receive I/O errors because of the standard approach where
    #     mod_ssl sends the close notify alert.
    #   o ssl-accurate-shutdown:
    #     This forces an accurate shutdown when the connection is closed, i.e. a
    #     SSL close notify alert is send and mod_ssl waits for the close notify
    #     alert of the client. This is 100% SSL/TLS standard compliant, but in
    #     practice often causes hanging connections with brain-dead browsers. Use
    #     this only for browsers where you know that their SSL implementation
    #     works correctly.
    #   Notice: Most problems of broken clients are also related to the HTTP
    #   keep-alive facility, so you usually additionally want to disable
    #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
    #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
    #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
    #   "force-response-1.0" for this.
    BrowserMatch "MSIE [2-6]" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>

Что касается журналов ошибок, в login.my-app.com.error.log просто есть несколько таких строк:

[Fri Apr 19 15:19:54 2013] [warn] RSA server certificate CommonName (CN) `Ubuntu-1204-precise-64-minimal' does NOT match server name!?

(Кстати: установка по умолчанию «Ubuntu-1204-точный-64-минимальный» была изменена в моем имени хоста и файлах хостов давно, поэтому я понятия не имею, почему он появляется здесь ...)

Журнал ssl-access.log пуст.

Мои сертификаты находятся в правильных папках и доступны для чтения (закрытый ключ только от root), и я также попытался использовать сертификаты змеиного масла по умолчанию в качестве теста. Результат тот же. Я уверен, что сайт включен (это единственный активный сайт), я уверен, что mod_ssl включен, и я уверен, что apache прослушивает 443.

Я пробовал комментировать многие директивы по одной и перезапускать, но ни одна из них не имеет никакого значения. Если я отключу этот сайт и снова включу по умолчанию, я перейду на сайт index.html по умолчанию без проблем, но как только SSL и HTTPS вводят изображение, я не могу получить то, что хочу. У меня нет идей!

Есть ли у кого-нибудь какие-нибудь идеи для меня?

Обновить

Выход подробный статус sudo ufw

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere
115/tcp                    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
22/tcp                     LIMIT IN    Anywhere
80/tcp (Apache)            ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere (v6)
115/tcp                    ALLOW IN    Anywhere (v6)
25/tcp                     ALLOW IN    Anywhere (v6)
80/tcp (Apache (v6))       ALLOW IN    Anywhere (v6)

Проверьте файл конфигурации приложения ufw Apache в /etc/ufw/applications.d/apache2.2-common и убедитесь, что у вас включено правильное правило. Похоже, у вас только что включено правило [Apache], которое по умолчанию разрешает только порт 80. Вы, вероятно, захотите включить правило [Apache Full], которое разрешит трафик через порт 80 и порт 443, или [Apache Save] разрешит только порт 443.


Оригинал:

Это может быть глупый вопрос, но проверяли ли вы также конфигурацию своего брандмауэра. Я предполагаю, что вы используете UFA по умолчанию

Проверьте статус с помощью: подробный статус sudo ufw

Для получения дополнительной информации см .: https://help.ubuntu.com/community/UFW