I have hosted my site on TCP port 91. Is there a way to bind their SSL certificate on that same port 91?
Estou interpretando esta pergunta como "Estou executando meu site em http://www.mysite.example:91/ e também quero executá-lo para HTTPS em https://www.mysite.example:91/ " (nesse caso, não é uma duplicação de Vários domínios SSL no mesmo endereço IP e na mesma porta? , marcados temporariamente).
Isso pode ser feito usando Unificação de Portas , que é suportado pelo Grizzly, por exemplo (um servidor web Java). (Sua pergunta não diz qual servidor você deseja usar.)
A unificação de porta pode funcionar para qualquer protocolo em que se espera que o cliente fale primeiro (por exemplo, HTTP, SSL / TLS, mas não IMAP, ...).
Essencialmente, o servidor tenta detectar qual protocolo é usado observando o início da solicitação antes de despachá-lo. Se receber GET / ... , pode assumir que é uma solicitação HTTP. Se ele receber um ClientHello , ele pode assumir que é uma solicitação SSL / TLS (que pode então ser redirecionada para o protocolo apropriado de cima, se necessário, neste caso HTTP por TLS ).
O suporte para esse recurso é bastante incomum, mas funciona. No entanto, você terá que especificar a porta explicitamente em seu URL, se não for o padrão (80 sempre será o padrão para http:// e 443 sempre será o padrão para https:// ).
Não estou ciente de que esse recurso está sendo implementado no Apache Httpd, mas isso não é, em princípio, um problema. Outras respostas mencionam que dois serviços (ou dois processos) não podem escutar na mesma porta. Isso é verdade, mas nada impede que o mesmo servidor / processo consiga lidar com vários sites (o Apache Httpd faz isso muito bem quando o mesmo processo escuta várias portas, por exemplo, 80 e 443, e faz o VirtualHost despachar na parte de trás) .
Voltando à " possível pergunta duplicada ", outra solução pode ter sido usar RFC 2817 , conforme mencionado em esta resposta . Infelizmente, embora essa resposta mencione esse RFC, os logs mostrados indicam que curl não havia tráfego HTTP simples antes do tráfego SSL / TLS, o que indicaria que estava usando a Indicação do Nome do Servidor (SNI) e não o RFC 2817. Além disso , Eu não estou ciente de qualquer implementação do RFC 2817, enquanto curl já tinha suporte para o SNI no momento da resposta.
O suporte ao RFC 2817 é muito mais complicado do que suportar a unificação de portas, já que requer suporte no lado do cliente e do servidor, incluindo a capacidade de atualizar no meio do protocolo. (Não é o fim do mundo, SMTP, LDAP e outros podem fazer isso, mas já é amplamente suportado por esses protocolos.)
Por outro lado, a unificação de portas requer apenas a alteração do mecanismo de despacho inicial no lado do servidor. Apenas especificando a porta explicitamente na URL, qualquer navegador irá suportá-la no lado do cliente.