Перенос SSL-сертификата на новый сервер

1. Первая часть:

   SSLCertificateFile /etc/apache2/ssl/11-2013/09********ss.crt
   

Это публичный сертификат для вашего сайта. Это тот, который вы бы rekey, чтобы изменить SHA1 на SHA2.

SSLCertificateKeyFile /etc/apache2/ssl/11-2013/server.key

Это частный сертификат для вашего веб-сервера.

SSLCertificateChainFile /etc/apache2/ssl/11-2013/gd_bundle.crt

Это промежуточный пакет сертификатов для развертывания сертификата вашего веб-сервера в корневом центре в godaddy (потому что их корневой сертификат по умолчанию не обязательно является доверенным для браузеров)

2. Это дает инструкции о том, как настроить NGINX для использования промежуточной цепочки сертификатов (что вам, скорее всего, понадобится, поскольку вам нужно было сделать это на своем сервере Apache): nginx docs: Настройка HTTPS-серверов

3. Вы не должны изменять конфигурацию сертификата в файле конфигурации NGINX. Когда у сертификата есть возможности, вы можете выключить и включить эти возможности в файле конфигурации (согласно ответу от fvu), но сначала вам нужно в основном «обновить» сам сертификат. У GoDaddy есть пара статей, которые могут быть полезны для этого, первая просто описывает, что вы делаете, когда вносите это изменение: https://www.godaddy.com/help/rekey-certificate-4976 второй расскажет вам, как это сделать, используя их сервис: https://www.godaddy.com/help/rekey-certificate-4976.

После того, как у вас есть все это на месте, вы можете использовать ssllabs для тестирования, но это будет работать только в том случае, если ваш новый сайт запущен и работает с правильным именем хоста в DNS (что вы, возможно, не захотите делать, если вам все еще нужен сайт. на Apache, пока вы не закончите). Предполагая, что у вас есть root-права на Linux / Unix-машине, вы можете использовать openssl для проверки:

1. Введите IP-адрес вашей новой службы NGINX в качестве имени сайта, который вы хотите протестировать. Таким образом, ваш основной сайт остается там, где он находится на Apache, вы только указываете своей локальной машине найти его на сайте NGINX. Как только вы это сделаете, запустите следующую команду и посмотрите, что она выдает:

   openssl s_client -connect hostname:port
   

Или используйте эту команду, которая указывает вам прямо на то, что вы проверяете: https://stackoverflow.com/questions/26473076/how-do-i-check-if-my-ssl-certificate-is-sha1-or-sha2-on-the-commandline

ssl_certificate_key должны содержать то, что сейчас находится в server.key, т.е. незашифрованный закрытый ключ сервера.

ssl_certificate должен содержать сертификат сервера и цепочку сертификатов, как объяснено в документации, в этой последовательности. Итак, это в основном результат cat 09********ss.crt gd_bundle.crt

Удобный онлайн-инструмент, чтобы быстро проверить, что именно каждый из этих -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- блоки содержат https://www.sslshopper.com/certificate-decoder.html - если у вас есть машина с установленным openssl, вы, конечно, можете использовать

openssl x509 -in certificate.crt -text -noout

Что касается конфигурации SSL / TLS, мне нравится это страница в вики Mozilla. В нем объясняется большинство сокращений, с которыми вы можете встретиться, и даются разумные советы относительно разумных конфигураций. Есть сопутствующий онлайн-инструмент, который создаст эталонные настройки для Apache, nginx, haproxy и AWS LB, Вот. Например, полная конфигурация nginx со сшиванием OCSP и HSTS с использованием промежуточного профиля выглядит так: но нужно понимать, что эти профили развиваются и поэтому должны регулярно обновляться.

server {
    listen 443 ssl;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /path/to/dhparam.pem;

    # intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    resolver <IP DNS resolver>;

    ....
}

После того, как все это будет установлено и протестировано, переходите к ssllabs и запустите тест. Если вы что-то пропустили, вы увидите, что еще нужно сделать.