У нас есть несколько поддоменов, каждый со своей собственной записью виртуального хоста в httpd.conf и (для тех, кто поддерживает https) также в ssl.conf. С нашим основным субдоменом www связан сертификат GoDaddy. Субдомен, который я настраиваю прямо сейчас в нашей среде разработки ("api.bulbstorm.com"), имеет запись виртуального хоста ssl.conf, которая выглядит следующим образом:
<VirtualHost 172.16.247.153:443>
DocumentRoot "/var/www/api"
ServerName api.bulbstorm.com:443
ErrorLog logs/api-error_log
CustomLog logs/api-access_log common
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCertificateFile /var/www/certs/api/server.crt
SSLCertificateKeyFile /var/www/certs/api/server.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
<Directory "/var/www/api">
Options +FollowSymLinks
RewriteEngine On
AllowOverride All
Order allow,deny
Allow from all
</Directory>
php_value include_path "/var/www/inc"
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
... файлы crt и ключей в / var / www / certs / api / были созданы с использованием openssl согласно найденным инструкциям Вот.
Поддомен api изначально указывал на сертификат godaddy для поддомена www. Но даже несмотря на то, что я изменил запись виртуального хоста, связанную с поддоменом api, чтобы указать на пару самозаверяющий сертификат / ключ (и перезапустил httpd, полностью очистил настройки браузера, связанные с предыдущим исключением для сертификата godaddy, и т. Д.) браузеры по-прежнему выдают предупреждения о том, что сертификат предназначен для домена www.. Когда я смотрю на сертификат, который вытаскивают браузеры, похоже, что они все еще получают сертификат godaddy.
Выше в файле ssl.conf есть следующие строки:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
Эта пара сертификат / ключ отличается от пары сертификат / ключ godaddy, указанной в записи виртуального хоста для субдомена www, которая выглядит следующим образом:
SSLCertificateFile /etc/www.bulbstorm.com_ssl/www.bulbstorm.com.crt
SSLCertificateKeyFile /etc/www.bulbstorm.com_ssl/www.bulbstorm.com.key
SSLCertificateChainFile /etc/www.bulbstorm.com_ssl/gd_intermediate_bundle.crt
Мы будем благодарны за любой свет, который кто-либо может пролить на мою проблему.
Как указывает Амишгик, а пинг подтверждает:
Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\Owner>ping bulbstorm.com
Pinging bulbstorm.com [216.139.247.153] with 32 bytes of data:
Control-C
^C
C:\Users\Owner>ping www.bulbstorm.com
Pinging www.bulbstorm.com [216.139.247.153] with 32 bytes of data:
Control-C
^C
C:\Users\Owner>ping api.bulbstorm.com
Pinging api.bulbstorm.com [216.139.247.153] with 32 bytes of data:
Control-C
^C
C:\Users\Owner>
У вас одинаковый IP-адрес для обоих хостов. SSL выполняется до отправки имен хостов. Имена хостов отправляются в Apache через заголовок Host: в HTTP-запросах. В OpenSSL 1.0 будет поддержка Сертификаты TLS, который может помочь с совместным использованием IP, но это еще одна игра, и многое другое Поиск в Google.
ССЫЛКИ:
РЕШЕНИЯ:
По Запись в Википедии о TLS: вам следует настроить свой сертификат для поддержки нескольких альтернативные имена субъектов (GoDaddy имеет "Сертификаты UCC") или получите сертификат с подстановочным знаком.
В зависимости от вашей пользовательской базы вы можете попросить пользователей поддержать корневой сертификат CACert и получить сертификат subjectAltName от них. (на самом деле, похоже, что в вашем текущем сертификате есть subjectAltName для Bulbstorm.com И www.bulbstorm.com). Это экономит 70 долларов в год. Поместите ссылку на свою страницу без SSL или на свою страницу SSL, которая говорит что-то вроде
"Вы получаете ошибки в браузере SSL? Мы используем CACert Сертификаты SSL. Пожалуйста, следуйте эта ссылка чтобы загрузить их корневые сертификаты в свой браузер."
Убедитесь, что vhosts api.bulbstorm.com и www.bulbstorm.com находятся на РАЗНЫХ IP-адресах. Вот мои конфигурации vhost для 2 разных поддоменов с уникальными сертификатами SSL:
Listen 10.0.0.152:443
<VirtualHost 10.0.0.152:443>
ServerAdmin admin@domain.com
DocumentRoot /web0/cloud/login.domain.com/current
ServerName login.domain.com
ServerAlias www.login.domain.com login.domain.com
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/www/login.domain.com-access_log
ErrorLog /var/log/www/login.domain.com-error_log
<DIRECTORY /web0/cloud/login.domain.com/current>
Allow from All
OPTIONS Indexes Includes ExecCGI FollowSymLinks
AllowOverride ALL
</DIRECTORY>
IndexOptions FancyIndexing
AddType application/x-httpd-php .html
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/usr/local/etc/apache22/ssl.crt/login.domain.com.crt"
SSLCertificateKeyFile "/usr/local/etc/apache22/ssl.key/login.domain.com.key"
SSLCertificateChainFile "/usr/local/etc/apache22/ssl.crt/comodo.ca-bundle"
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
Listen 10.0.0.151:443
<VirtualHost 10.0.0.151:443>
ServerAdmin admin@domain.com
DocumentRoot /web0/cloud/admin.domain.com/current
ServerName admin.domain.com
ServerAlias www.admin.domain.com admin.domain.com
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/www/admin.domain.com-access_log
ErrorLog /var/log/www/admin.domain.com-error_log
<DIRECTORY /web0/cloud/admin.domain.com/current>
Allow from All
OPTIONS Indexes Includes ExecCGI FollowSymLinks
AllowOverride ALL
</DIRECTORY>
IndexOptions FancyIndexing
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/usr/local/etc/apache22/ssl.crt/admin.domain.com.crt"
SSLCertificateKeyFile "/usr/local/etc/apache22/ssl.key/admin.domain.com.key"
SSLCertificateChainFile "/usr/local/etc/apache22/ssl.crt/comodo.ca-bundle"
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
Чтобы ответить на ваш вопрос в самом конце, вот как сгенерировать самоподписанный сертификат SSL.
Во-первых, эта строка сгенерирует закрытый ключ, который используется для создания запроса на подпись сертификата (CSR).
openssl genrsa -des3 -out server.key 1024
Вам будет предложено ввести кодовую фразу. Эта кодовая фраза зашифрует закрытый ключ. Следующая строка сгенерирует CSR с использованием вашего закрытого ключа.
openssl req -new -key server.key -out server.csr
Затем вам будет предложено ввести следующие вопросы (и вашу парольную фразу, если вы решили использовать ее при создании своего закрытого ключа).
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Изменить: если вы создаете самозаверяющий сертификат для тестирования, Common Name поле выше - это то место, где вы хотите разместить свой домен (именно так, как вы этого хотите, т. е. с www если вы хотите, чтобы это был тот адрес, который вы используете). После создания CSR вы можете самостоятельно подписать его, выполнив следующие действия.
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Тогда у вас будет ваш закрытый ключ (server.key) и ваш сертификат SSL (server.crt), который вы можете установить в Apache, используя директивы, которые вы использовали выше для других сертификатов.
Я не уверен, что это отвечает на какие-либо вопросы, касающиеся явно неправильного сертификата, отправляемого в браузер, но я бы предложил, возможно, удалить все ссылки на файлы сертификатов за пределами этого VirtualHost чтобы увидеть, происходит ли это по-прежнему, поскольку вы действительно можете иметь только один хост SSL на IP-адрес и иметь несколько SSLCertificateFile директивы могут иметь необычный эффект.