В этом вопросе будет много невежества, поэтому, пожалуйста, примите следующие меры:
Насколько я понимаю, стандартное соединение SSL между браузером и клиентом включает:
Если я уже искалечил его, поправьте меня до сих пор, но теперь я пытаюсь понять, что происходит, когда SSL-соединение выполняется с одного сервера, действующего как клиент, на другой сервер, действующий как сервер, а PHP сделать звонок. По сути, это тот же процесс? Выполняет ли клиент-сервер те же шаги, что и клиент-браузер?
В среде apache нужно ли настраивать клиент-сервер определенным образом?
По сути, у вас есть процесс. Особенности того, как ваш PHP-код будет действовать при проверке сертификата сервера, будет зависеть от метода, который вы используете для доступа к серверу. PHP библиотека cURL, например, имеет параметр CURLOPT_SSL_VERIFYPEER, который вы можете установить чтобы библиотека проверила сертификат партнера.
Поскольку вы явно призвали педантизм:
№1. Браузер подключается к серверу через HTTPS
Это неверно. Браузер подключается к серверу (почти всегда) через TCP (почти всегда) через порт HTTPS, 443. Весь этот процесс можно рассматривать как подключение браузера через HTTPS, но тогда остальная часть процесса является избыточной.
№2. Браузер запрашивает SSL-сертификат сервера
Это верно; более конкретно, браузер отправляет ClientHello, который состоит из номера версии протокола, случайно сгенерированного nonce, идентификатор сеанса SSL (не связанный с такими вещами, как PHPSESSID; это, по сути, взлом, чтобы избежать дорогостоящей регенерации секретного ключа), поддерживаемые наборы шифров клиента (см. openssl ciphers) и неиспользуемое поле, изначально предназначенное для поддержки сжатия.
Затем сервер отвечает ServerHello, своим сертификатом, необязательным ключом nonce и необязательным запросом сертификата клиента (используется очень редко). Затем он отправляет Done, чтобы браузер знал, что ждет ответа.
№3. Браузер проверяет сертификат по стороннему ЦС (центру сертификации), который его выпустил.
Браузер также может использовать дополнительные сертификаты в цепочке, либо локально кэшированные, либо предоставленные вместе с сертификатом сервера, чтобы вернуться к надежному ЦС. Каждый сертификат также проверяется на наличие разрешений - то, что у меня есть сертификат для somesite.com, не означает, что я могу использовать этот сертификат для подписи сертификата для другого сайта.com; у моего сертификата somesite.com есть ограничение, в котором говорится, что нельзя подписывать подчиненные сертификаты.
№4. Браузер и сервер общаются через открытое SSL-соединение, и сертификат не требуется / не загружается повторно, пока не будет установлено новое соединение (т.е. следующая обратная передача).
Фактически есть еще две (с половиной) биржи; клиент должен доказать, что владеет ClientCert, и он должен предложить главный секрет, который он отправит на сервер, зашифрованный открытым ключом сервера. Поскольку только владелец закрытого ключа, связанного с сертификатом, отправленным сервером, может расшифровать этот ключ, клиенту гарантируется, что только его предполагаемый получатель имеет выбранный им главный секрет. Клиент также подтверждает, что он готов начать отправку фактических зашифрованных данных, и хэширует все данные до этого момента, чтобы сервер мог знать, что он все время разговаривал с одним и тем же клиентом. Наконец, сервер подтверждает, что они собираются начать разговор, используя взаимно известный (но секретный для перехватчика) симметричный ключ, и хеширует все свои данные, чтобы доказать клиенту, что все находятся на одной странице. После этого HTTP работает как обычно, проходя через поток записи, который разбивает его и шифрует, в то время как отдельный поток предупреждений используется для управления самим сеансом.
Возвращаясь к теме, в вашем конкретном случае тот факт, что сервер, выдающий запрос, сам по себе является сервером, не имеет значения. С точки зрения сервера, к которому он подключается, это просто еще один клиент. Единственная странность заключается в том, что сервер-клиент не имеет возможности интерактивно обрабатывать ошибки аутентификации сертификата, поэтому вам нужно убедиться, что вы обработали их заранее, либо полностью отключив аутентификацию сертификата (для тестирование, а не для производства, конечно!), или путем обеспечения доступности соответствующих сертификатов CA для выбранного вами метода подключения HTTPS.
Единственная разница в том, что вы будете писать код, а не, скажем, Mozilla. Так что при желании вы можете решить, что недействительные сертификаты по-прежнему будут работать. Но да, действует тот же принцип. «Сервер» - это неправильное название. Ваш сервер является клиентом в соединении, которое он открывает с этим другим сервером. Таким образом, разница заключается в том, что вы пишете клиентский код, а не используете его.