При использовании Apache с SSL весь сертификат, указанный в директиве SSLCertificateFile, передается клиенту?

Клиенту передается только открытый ключ. В SSLcertificatefile указывает открытый ключ и директиву SSLcertificateKeyFile Директива предназначена для закрытого ключа.

Если вы хотите точно увидеть, что передается, вы можете использовать openssl для подключения и просмотра сертификата. Такая команда openssl s_client -connect www.google.org:443 подключится к Google, и вы увидите публичный сертификат и некоторые сведения о сертификате.

Только сертификат (который содержит открытый ключ и дополнительную информацию, такую ​​как идентификатор машины, но не закрытый ключ) отправляется клиенту. Если есть цепочка к CA (либо через SSLCertificateChainFile или через SSLCACertificatePath или SSLCACertificateFile) необходимо отправить цепочку сертификатов. Вы увидите полную цепочку с -showcerts варианты с openssl s_client:

echo | openssl s_client -showcerts -connect www.your.host.example:443

Вы можете, но не обязаны помещать закрытый ключ в тот же файл, его можно разделить на SSLCertificateKeyFile.

Это заняло у меня много времени, чтобы осознать, но как только вы это понимаете, он просто щелкает.

Apache этого не сделает. По уважительной причине.

Вы ведь видели те CSR, которые отправляете, чтобы получить CSR, верно? С информацией (общее название, город, штат и т. Д.)

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

Итак, теперь вы отправляете эти смешанные данные в какой-то веб-браузер, когда он попадает на вашу страницу, браузер использует ваш открытый ключ для декодирования этой информации. Если открытый ключ правильный, браузер видит (общее имя, город, штат и т. Д.) И знает, что парень, с которым он разговаривает, законен.

Если бы закрытым ключом был какой-то случайный сервер, эти смешанные данные были бы расшифрованы, чтобы получить более смешанные данные. Полный барахло. В этот момент браузер знает, что разговаривает с самозванцем.

Кроме того, браузер использует открытые ключи от человека, который подписал ваш исходный ключ (например, verisign или godaddy), потому что это хорошо известные и надежные источники ... Они делают это, чтобы убедиться, что они разговаривают с нужным человеком. Вот почему вы обычно получаете сертификаты от кого-то вроде Verisign.

Кроме того, вы можете подписывать свои собственные сертификаты, и ваши пользователи (например, в домене AD) доверяют вам, но вы должны убедиться, что все машины ваших пользователей доверяют вашей «подписывающей стороне». Это следующий уровень ...

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

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