Configurando https com um certificado autoassinado no Apache

Question

Estou tentando configurar o HTTPS no Apache, usando um certificado autoassinado. Mas em vez de exibir a página, recebo um monte de erros estranhos. Um erro diferente de cada navegador!

Do Chrome:

Error 2 (net::ERR_FAILED): Unknown error.

Do Firefox:

SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

Eu segui as etapas detalhadas no link , além de outros quatro guias. Eles são todos iguais, mas todos dão o mesmo resultado. Então devo estar fazendo algo errado.

Resumidamente, eis o que fiz:

• Gere a chave do servidor:

  openssl genrsa -des3 -out server.key 1024

• Gerar CSR:

  openssl req -new -key server.key -out server.csr

[durante a geração da solicitação, tive o cuidado de inserir meu nome de host real como o "Nome comum (por exemplo, seu nome ou o nome do host do seu servidor)"]

• remova a senha da chave:

  cp server.key server.key.org e openssl rsa -in server.key.org -out server.key

• Assinatura automática do certificado:

  openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

• Configurou o apache para apontar para esses arquivos e usar esses certificados.

Alguma idéia?

UPDATE: Aqui está minha configuração de host virtual:

LoadModule ssl_module modules/mod_ssl.so
Listen 443
#   Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin

## Virtual host to redirect to HTTPS
<VirtualHost *:80>
    ServerName mail.craimer.org
    Redirect permanent / https://mail.craimer.org:443
</VirtualHost>

##
## SSL Virtual Host Context
##

<VirtualHost mail.craimer.org:443>
    ServerName mail.craimer.org
    DocumentRoot "/usr/share/roundcubemail/trunk/roundcubemail/"

         ErrorLog logs/ssl_error_log
         TransferLog logs/ssl_access_log
         LogLevel warn

         SSLEngine on

         SSLProtocol all -SSLv2

         SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

         SSLCertificateFile /etc/httpd/conf/ssl/server.crt
         SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key

         <Files ~ "\.(cgi|shtml|phtml|php3?)$">
                                SSLOptions +StdEnvVars
         </Files>
         <Directory "/var/www/cgi-bin">
                                SSLOptions +StdEnvVars
         </Directory>

    # Deal with broken MSIE
         SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

    CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

    

Answer 1

Bem, desde que o usuário Jure1873 não escreveu uma resposta, eu não posso dar a ele o merecido crédito. Aqui está sua solução:

what if you replace <VirtualHost mail.craimer.org:443> with <virtualhost *:443>?

E essa foi a solução. Acontece que (no momento em que escrevo) httpd não pode suportar múltiplos hosts virtuais para HTTPS, então qualquer conexão com 443 deve ser direcionada para um único host. Então, eu acho que httpd estava rejeitando silenciosamente a configuração que tentava executar um host virtual para HTTPS.

Ah, e não critique o apache por esse "recurso ausente". Não é culpa deles! O protocolo HTTPS não suporta hosts virtuais.

Explicação entediante:

Você vê, quando você se conecta à porta 443 e inicia uma sessão HTTPS, tudo o que está acontecendo é a negociação de segurança. HTTPS é tudo sobre a criação de um túnel seguro entre dois pontos e não tem nada a ver com HTTP. Somente quando o túnel estiver configurado, os dados serão transmitidos. Esses dados são o fluxo HTTP.

Isso significa que a diretiva Host: (que faz parte do HTTP, não HTTPS) só será enviada após o túnel seguro ter sido construído. É o cabeçalho Host: que informa ao servidor HTTP qual host virtual está sendo acessado. Mas no HTTPS, nós obtemos essa informação tarde demais: ela chega depois que precisamos escolher as chaves de criptografia.

Conclusão: HTTPS não pode escolher chaves de criptografia com base no nome de host HTTP .

    

Answer 2

É mais provável que o problema esteja na configuração do vhost.

O erro ssl_error_rx_record_too_long pode ser produzido iniciando uma sessão HTTPS em um recurso HTTP. Tais como - https://host.name:80 .

    

Answer 3

A abordagem que usei no passado é ligeiramente diferente da que você detalhou. As instruções abaixo foram originalmente detalhadas neste post que encontrei enquanto procurava configurar o ssl: Instalação passo a passo do Subversion sobre o Apache / SSL autenticando através do Active Directory (SSPI)

Para resumir:

1. Em apache \ bin, crie openssl.conf e defina seu conteúdo da seguinte forma:

   [ v3_ca ] 
   subjectKeyIdentifier = hash 
   authorityKeyIdentifier = keyid:always,issuer:always 
   basicConstraints = CA:true 
   [ req ] 
   default_bits  = 1024 
   default_keyfile  = server.key 
   distinguished_name = req_distinguished_name 
   attributes  = req_attributes 
   x509_extensions = v3_ca  
   string_mask  = nombstr 
   [ req_distinguished_name ]  
   commonName  = Common Name 
   commonName_default = My Server Name 
   [ req_attributes ]

2. Abra um prompt de comando, navegue até apache \ bin e execute o seguinte comando:

   openssl req -config openssl.conf -new -out server.csr

3. Quando solicitado, insira uma frase secreta e, em seguida, uma segunda vez para verificar.

4. Você será solicitado a inserir um nome comum [My Server Name]. Digite o nome da máquina

5. Em seguida, remova a frase secreta da chave privada com o seguinte comando (observe que isso pode dar um aviso sobre não conseguir encontrar o arquivo openssl.conf - isso pode ser ignorado):

   openssl rsa -in server.key -out server.key

6. Digite a senha usada anteriormente quando solicitado

7. Em seguida, crie o certificado auto-assinado com o seguinte comando

   'openssl x509 -no servidor.csr -out server.cert -req -signkey server.key -days 365

8. Exclua o arquivo server.csr da pasta apache \ bin.

9. Copie os arquivos server.key e server.cert da pasta apache \ bin para a pasta apache \ conf.

10. Abra o apache \ conf \ httpd.conf em um editor de texto.

11. Altere a diretiva de porta de escuta (que provavelmente será Listen 80 ou Listen 8080) para a porta 443:

    Listen 443

12. Altere a diretiva ServerName para incluir a porta 443 (observe que isso pode estar comentado, remova o # no início da linha, se estiver, e substitua o servidor pelo nome do servidor):

    ServerName server:443

13. Remova o comentário ou adicione a diretiva do módulo de carregamento para mod_ssl (isso deve estar presente e comentado, portanto remova o # no início da linha):

    LoadModule ssl_module modules/mod_ssl.so

14. Adicione uma seção IfModule para mod_ssl (isso já não deveria estar lá, mas se for sobrescrevê-la):

    <IfModule mod_ssl.c>
        SSLEngine on
        SSLRandomSeed startup   builtin
        SSLRandomSeed connect   builtin
        SSLPassPhraseDialog     builtin
        SSLSessionCache         dbm:logs/ssl_scache
        SSLSessionCacheTimeout  300
        SSLMutex                default
        SSLCertificateFile      conf\server.cert
        SSLCertificateKeyFile   conf\server.key
    </IfModule>

15. Reinicie o serviço Apache. Teste a configuração tentando (e não) conectar-se via http e tentando (e bem-sucedido) se conectar via https.

Answer 4

Remova a tag da configuração do VirtualHost. POR EXEMPLO. %código% - remova essas linhas

    

Answer 5

Aqui está mais uma situação na qual esse erro ocorre:

Defina VirtualHost *:80 em sites-enabled/000-default.conf .     Em seguida, defina VirtualHost *:443

em httpd.conf

Se você mover a configuração completamente para httpd.conf ou para 000-default.conf , isso funcionará. Senão você recebe este erro no FireFox:

SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

e este erro no chrome:

This site can’t provide a secure connection
... sent an invalid response.

    

Answer 6

Entendido, a resposta aceita está errada, caso contrário, por que você acha que a diretiva SSLCertificateFile pode estar no escopo do host virtual? Prova: link

Com hosts virtuais, você ainda pode usar diferentes arquivos de certificados com hosts virtuais baseados em nome.

Eu tive o mesmo problema e a solução foi colocar IP real em vez de * na diretiva VirtualHost, assim:

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost 127.0.0.1:443>
  ServerName affx.meg
  ...
</VirtualHost>

P.S. Hovewer Eu não sei porque funcionou. Eu apenas peguei essa configuração como um exemplo do servidor live real e a reutilizei na minha configuração e funcionou.