421 Solicitação incorreta usando SSL HTTP / 2 e SAN

Question

Estou executando o Apache 2.4.20 no Ubuntu e tenho o SSL configurado. Tenho um certificado SSL SAN e www.example.com e www2.example.com compartilho o mesmo certificado.

Estou recebendo um erro 421 Solicitação incorreta quando incluo o seguinte:

Protocols h2 h2c http/1.1
H2Upgrade on
H2Direct
H2WindowSize 128000

Os sites são executados normalmente se eu removê-los.

Estou recebendo o erro se, NA MESMA BROWSER, www.example.com e www2.example.com estiverem abertos. Se eu for primeiro a www.example.com , ele será carregado corretamente. Recebo o erro quando carrego um segundo site desse certificado SSL da SAN, como www2.example.com . Não importa qual site eu vou primeiro. Ele sempre responde com o 421 Pedido Indevido no segundo site.

O que há de errado com meu uso das diretivas HTTP / 2? (Eles estão no VirtualHost pelo caminho)

Ou há um problema com as implementações HTTP / 2 e SAN SSL?

E, se for importante, tanto o www.example.com quanto o www2.example.com estão no mesmo servidor hospedado na AWS.

Obrigado.

EDITAR:

Eu também tentei as configurações abaixo com os mesmos resultados.

Protocols h2 http/1.1
H2Direct
H2WindowSize 128000

Na configuração SSL

<IfModule mod_ssl.c>

    SSLRandomSeed startup builtin
    SSLRandomSeed startup file:/dev/urandom 512
    SSLRandomSeed connect builtin
    SSLRandomSeed connect file:/dev/urandom 512

    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl

    SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase

    SSLSessionCache     shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
    SSLSessionCacheTimeout  300

    SSLOpenSSLConfCmd DHParameters "/path/dhparams.pem"

    SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    SSLHonorCipherOrder on

    SSLCompression Off
    SSLSessionTickets Off

    SSLUseStapling On
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_stapling(32768)

    SSLProtocol all -SSLv3

    SSLInsecureRenegotiation Off
    SSLStrictSNIVHostCheck Off

</IfModule>

No VirtualHost

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerAdmin [email protected]
    ServerName www.example.com
    DocumentRoot /path/path

    Protocols h2 http/1.1
    H2Direct on
    H2WindowSize 128000

    SSLEngine on
    SSLCACertificateFile /path/cert.crt
    SSLCertificateFile /path/cert.crt
    SSLCertificateKeyFile /path/key.key

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

    <Directory /path/path>
        AllowOverride None
        Require all granted
    </Directory>

 </VirtualHost>
</IfModule>

    

Answer 1

Este foi um problema real para mim. Mas encontrei a resposta aqui .

Vários hosts e solicitações mal direcionadas

Many sites use the same TLS certificate for multiple virtual hosts. The certificate either has a wildcard name, such as '*.example.org' or carries several alternate names. Browsers using HTTP/2 will recognize that and reuse an already opened connection for such hosts.

While this is great for performance, it comes at a price: such vhosts need more care in their configuration. The problem is that you will have multiple requests for multiple hosts on the same TLS connection. And that makes renegotiation impossible, in face the HTTP/2 standard forbids it.

So, if you have several virtual hosts using the same certificate and want to use HTTP/2 for them, you need to make sure that all vhosts have exactly the same SSL configuration. You need the same protocol, ciphers and settings for client verification.

If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client.

Eu tenho 3 VirtualHosts compartilhando o mesmo certificado. Ambos são configurados usando minha configuração SSL "padrão". O último deles tinha uma configuração especial, pois eu não precisava que o último fosse compatível com muitos navegadores, então usei cifras mais modernas e apenas o mais recente protocolo SSL. Aquele VirtualHost em particular "especial" estava recebendo o 421.

Se eu desabilitar o protocolo h2 http / 1.1, isso resolveria o problema, mas eu não queria desabilitar isso.

Depois de usar a mesma configuração em todos os VirtualHost compartilhando o mesmo certificado, o problema foi corrigido .

    

Answer 2

Eu encontrei esse problema hoje e fiquei um pouco intrigado no começo, porque eu não usei nenhuma cifra diferente, então eu não pude entender o que a nota "se você misturar coisas" da resposta acima era realmente sobre. Bem, descobriu-se que não é suficiente se SSLCertificateFile e SSLCertificateKeyFile tiverem o mesmo conteúdo e se os arquivos forem cópias idênticas entre si. Essas configurações precisam apontar para o mesmo arquivo! Eu suspeito que isso seja, porque não é o navegador que realmente vê um problema (como eu pensava inicialmente ser o caso), mas o Apache já está detectando que a configuração não é a mesma e bloqueia qualquer requisição HTTP2 preventivamente porque espera que o navegador Vai ter um problema se realmente entregou a página (o que provavelmente pode muito bem acontecer de fato). O Apache também está gravando um erro correspondente em seu arquivo de log ("Hostname www.example.com fornecido via SNI e hostname www2.example.com fornecidos via HTTP não possuem configuração SSL compatível"). Este teste de compatibilidade de configuração parece ser bastante simples e não se importa com o fato de que o certificado é de fato o mesmo. Provavelmente, só percebe os diferentes nomes de arquivos / caminhos e, em seguida, rejeita.