Откуда взялся этот универсальный SSL-сертификат?

Откуда взялся этот универсальный SSL-сертификат?

Моя компания размещает example.com и sub.example.com на одном сервере, используя wildcard SSL-сертификат для *.example.com. Теперь пришло время обновить наш сертификат, и мы не уверены, как мы его получили. Мой босс не думает, что мы заплатили 200 долларов, которые он, по-видимому, стоит. Мой старый менеджер (который ушел из компании несколько дней назад) был тем, кто установил его, и он не помнит точно, что он сделал, но он думает, что ему нужно было что-то сгенерировать, а не просто использовать файлы, которые нам предоставил CA.

В конфигурации Apache есть следующие строки и нет других незакомментированных строк SSL*File:

SSLCertificateFile /usr/local/ssl/cert/example.com.crt
SSLCACertificateFile /usr/local/ssl/cert/intermediate.crt
SSLCertificateKeyFile /usr/local/ssl/private/example.com-wild.key

Когда я проверяю файл intermediate.crt ( openssl x509 -in intermediate.crt -text -noout), в нем вообще не упоминается наша организация или веб-сайт, и он действителен в период 2010–2020 гг.

Data:
    Version: 3 (0x2)
    Serial Number: 145105 (0x236d1)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
    Validity
        Not Before: Feb 19 22:45:05 2010 GMT
        Not After : Feb 18 22:45:05 2020 GMT
    Subject: C=US, O=GeoTrust, Inc., CN=RapidSSL CAb

example.com.crt — это подстановочный знак:

Data:
    Version: 3 (0x2)
    Serial Number: 1113972 (0x10ff74)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=GeoTrust, Inc., CN=RapidSSL CA
    Validity
        Not Before: Mar  1 09:05:39 2014 GMT
        Not After : Mar  4 09:08:54 2015 GMT
    Subject: serialNumber=T0nuTvfeaQVtd3dZ30zGI94HrvUsoRjx, OU=GT53409919, OU=See www.rapidssl.com/resources/cps (c)14, OU=Domain Control Validated - RapidSSL(R), CN=*.example.com

Я не понимаю инфраструктуру SSL, поэтому, полагаю, у меня есть куча связанных вопросов. Прошу прощения, если они окажутся совсем не связанными; я не знаю, чего я не знаю.

  • Как мы получили wildcard-сертификат, если мы не заплатили за него 200 долларов или что-то в этом роде? (Я был бы несколько удивлен, если бы мы могли создать его с помощью только intermediate.crt, потому что тогда мы могли бы продолжать генерировать их до 2020 года. Но в /usr/local/ssl нет других файлов, и в /etc/pki/tls нет ничего, что было бы изменено с 2013 года, так что что еще мы могли бы использовать? Я также был бы несколько удивлен, если бы мой босс просто неправильно помнил, и мы действительно заплатили 200 долларов или что-то в этом роде, но мне это кажется возможным.)

  • Откуда мы взяли intermediate.crt?

  • Что делает intermediate.crt? У меня есть самоподписанный wildcard-сертификат, который отлично работает (за исключением того, что он самоподписанный) на наших бета-серверах, без строки SSLCACertificateFile; и мы купили не-wildcard-сертификат, который защищает example.com, который мне удалось установить с помощью VirtualHost без SSLCACertificateFile, и мы находимся в процессе получения сертификата для sub.example.com, который я планирую установить таким же образом. Нужен ли SSLCACertificateFile для не-самоподписанных wildcard-сертификатов?

    Способ, которым я сгенерировал самоподписанный сертификат, кажется мне связанным:

    openssl req -nodes -new -keyout private/example.com.key -out certs/intermediate.csr
    openssl x509 -req -days 365 -in certs/intermediate.csr -signkey private/file.key -out certs/example.com.crt
    

    но в этом случае мне не нужно упоминать промежуточный.csr в конфигурации Apache, и промежуточный.csr не может быть проверен так, openssl x509как файл промежуточный.crt.

решение1

How did we get the wildcard certificate, if we didn't pay $200 or whatever for it?

Более дешевый CA, чем вы нашли сейчас? Я уверен, что вы найдете реселлера с более низкими ценами.

Where did we get intermediate.crt? What does intermediate.crt do?

Вы получаете его из своего CA. CA обычно не подписывают сертификаты напрямую с помощью своих корневых сертификатов, а делают это через промежуточный сертификат. Этот промежуточный сертификат подписывает сертификаты для клиента и, в свою очередь, подписывается корневым сертификатом, которому доверяют браузеры и ОС. Это называется цепочкой сертификатов, и это также причина, по которой существует отдельный параметр для Apache, SSLCACertificateFileчтобы предоставить эту цепочку от сертификата веб-сайта до сертификата CA.

У меня есть самоподписанный wildcard-сертификат, который отлично работает (за исключением того, что он самоподписанный) на наших бета-серверах, без строки SSLCACertificateFile;

Тогда браузер, который вы тестировали, также доверяет промежуточному сертификату, но вы не можете полагаться на это. Вы также можете использоватьSSLLabs ssltestинструмент для проверки вашей цепочки на предмет неполноты или пропуска промежуточного звена (так называемая дополнительная загрузка).

Нужен ли SSLCACertificateFile для несамоподписанных wildcard-сертификатов?

Нет, поскольку в данном случае цепочка сертификатов отсутствует, см. выше.

решение2

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

Связанный контент