Haverá muita ignorância nesta questão, por favor, tenha em conta:
Meu entendimento de uma conexão SSL cliente-navegador-servidor padrão envolve:
Se eu já tiver estragado tudo, corrija-me até agora, mas agora estou tentando entender o que acontece quando uma conexão SSL é feita a partir de um servidor agindo como um cliente para outro servidor agindo como servidor, e o PHP está fazendo a chamada. É essencialmente o mesmo processo? O cliente-servidor passa pelas mesmas etapas que o navegador-cliente?
Em um ambiente apache, o cliente-servidor precisa ser configurado de uma determinada maneira?
Você tem o processo, essencialmente. As especificidades de como seu código PHP agirá na verificação do certificado do servidor dependerá do método que você está usando para acessar o servidor. A biblioteca cURL do PHP , por exemplo, tem uma opção 'CURLOPT_SSL_VERIFYPEER' que você pode definir para fazer a biblioteca verificar o certificado do mesmo.
A única diferença é que você vai escrever o código em vez de dizer Mozilla. Então, se você quiser, pode decidir que certificados não válidos continuarão funcionando. Mas sim, o mesmo princípio se aplica. "Servidor" é apenas um equívoco. Seu servidor é o cliente na conexão que ele abre para esse outro servidor. Então a diferença gira em torno do fato de que você está escrevendo o código do cliente em vez de usá-lo.
Desde que você convidou explicitamente o pedantismo:
#1. Browser connects to server via HTTPS
Isso está incorreto. O navegador se conecta ao servidor (quase sempre) via TCP, (quase sempre) na porta HTTPS, 443. Todo esse processo pode ser considerado como o navegador se conectando via HTTPS, mas o resto do processo é redundante.
#2. Browser requests server SSL certificate
Isso está correto; mais especificamente, o navegador envia um ClientHello, que consiste em um número de versão do protocolo, um nonce gerado aleatoriamente, uma sessão SSL ID (não relacionado a coisas como PHPSESSID; isso é basicamente um hack para evitar a regeneração de chave secreta), os conjuntos de criptografias suportados do cliente (veja openssl ciphers ) e um campo não usado originalmente destinado a suportar compressão.
O servidor responde com um ServerHello, seu certificado, uma chave nonce opcional e uma solicitação opcional para o certificado do cliente (muito raramente usado). Em seguida, envia um Done para que o navegador saiba que está aguardando sua resposta.
#3. Browser verifies certificate against the third party CA (certificate authority) that issued it.
O navegador também pode usar certificados adicionais na cadeia, armazenados em cache local ou fornecidos junto com o certificado do servidor, para encadear de volta a uma CA confiável. Cada certificado é verificado para permissões, também - só porque eu tenho um certificado para somesite.com não significa que eu posso usar esse certificado para assinar um certificado para anothersite.com; meu somesite.com cert tem uma restrição dizendo que não é permitido assinar certificados subordinados.
#4. Browser and server speak over an open SSL-connection, and certificate is not needed/downloaded again until a new connection is established (i.e. the next postback).
Na verdade, existem duas (e meia) mais trocas; o cliente tem que provar sua posse do ClientCert, e tem que propor um segredo pré-mestre, que será enviado para o servidor, criptografado pela chave pública do servidor. Uma vez que apenas o detentor da chave privada associada ao certificado enviado pelo servidor pode descriptografar essa chave, o cliente tem a garantia de que apenas o destinatário pretendido possui o segredo pré-mestre selecionado. O cliente também confirma que está pronto para começar a enviar dados reais e criptografados e coloca todos os dados em hash até o momento, para que o servidor possa saber que estava falando com o mesmo cliente o tempo todo. Finalmente, o servidor confirma que eles estão prestes a começar a falar usando a chave simétrica mutuamente conhecida (mas secreta a um interceptador) e criptografa todos os seus dados para provar ao cliente que todos estão na mesma página. Depois disso, o HTTP acontece normalmente, passando por cima do fluxo de registro, que o corta e criptografa, enquanto um fluxo de alerta separado é usado para gerenciar a própria sessão.
Voltando ao assunto, no seu caso específico, o fato de o servidor que está emitindo o pedido ser, ele próprio, um servidor, é irrelevante. Do ponto de vista do servidor ao qual está se conectando, é apenas outro cliente. O único ponto estranho é que o servidor-cliente não tem a capacidade de lidar interativamente com os erros de autenticação de certificado, então você precisa ter certeza de que os tratou antes, desabilitando a autenticação do certificado por completo (por exemplo, teste, não para produção, é claro!), ou garantindo que os certificados de CA apropriados estejam disponíveis para o método de conexão HTTPS que você escolheu.
Tags security ssl apache-2.2