O problema foi resolvido, mas houve alguns mal-entendidos. Existe realmente o requisito de que HTTPS precisa de um certificado correspondente, mas o problema causado por isso é que a conexão não será confiável com o nome do host certificados correspondentes Nome comum ou listados em Nome alternativo do assunto :
-
A mesma incompatibilidade permanece igual à solução
RewriteRule
dada na outra resposta. -
Se os nomes de host "pega-tudo" forem todos subdomínios de
example.com
e você tiver um certificado curinga para*.example.com
, ele corresponderá. -
Por outro lado, a maioria das pessoas, ao tentar acessar
something.example.com
, o digita na barra de endereço do navegador sem o prefixohttp://
ouhttps://
e o padrão dos navegadores é HTTP. Portanto, ter um redirecionamento "catch-all" em HTTPS, mesmo com certificados incompatíveis, geralmente não causará problemas reais: apenas algumas pessoas já veem o erroSSL_ERROR_BAD_CERT_DOMAIN
.
A Correspondência de host virtual funciona da mesma maneira com ou sem TLS.
Se você não tiver SNI :
The first name-based vhost in the configuration file for a given
IP:port
pair is significant because it is used for all requests received on that address and port for which no other vhost for thatIP:port
pair has a matchingServerName
orServerAlias
. It is also used for all SSL connections if the server does not support Server Name Indication.
Sem o SNI , o certificado do primeiro VirtualHost
é usado para handshake:
In reality, Apache will allow you to configure name-based SSL virtual hosts, but it will always use the configuration from the first-listed virtual host (on the selected IP address and port) to setup the encryption layer.
O principal problema com sua tentativa original era ter ServerAlias *
e não ter ServerName
. Para um host "pega-tudo", ele teria trabalhado com qualquer coisa, menos os outros ServerName
s de outros VirtualHost
s. Se não houver outra correspondência, o Apache volta para a seção VirtualHost
padrão; seja qual for a primeira seção (que corresponde à pesquisa baseada em IP, quando a pesquisa baseada em nome falha).
Name-based virtual hosts for the best-matching set of
<virtualhost>
s are processed in the order they appear in the configuration. The first matchingServerName
orServerAlias
is used, with no different precedence for wildcards (nor forServerName
vs.ServerAlias
).
Deve haver ALGUMA ServerName
porque:
The
ServerName
directive may appear anywhere within the definition of a server. However, each appearance overrides the previous appearance (within that server).If no
ServerName
is specified, the server attempts to deduce the client visible hostname by first asking the operating system for the system hostname, and if that fails, performing a reverse lookup on an IP address present on the system.
Isso resultaria em configuração assim:
<VirtualHost *:443>
# Default catch-all (everything that won't match the following VirtualHosts)
ServerName catch-all.example.com
ServerAlias www.example.com
SSLEngine on
SSLCertificateFile "C:/prod/hosts.crt.pem"
SSLCertificateKeyFile "C:/prod/hosts.key.pem"
SSLCertificateChainFile "C:/prod/intermediate.crt.pem"
Redirect permanent / https://example.com
</VirtualHost>
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile "C:/prod/hosts.crt.pem"
SSLCertificateKeyFile "C:/prod/hosts.key.pem"
SSLCertificateChainFile "C:/prod/intermediate.crt.pem"
Include conf/sites/example.com.conf
</VirtualHost>
<VirtualHost *:443>
ServerName dev.example.com
SSLEngine on
SSLCertificateFile "C:/prod/hosts.crt.pem"
SSLCertificateKeyFile "C:/prod/hosts.key.pem"
SSLCertificateChainFile "C:/prod/intermediate.crt.pem"
Include conf/sites/dev.example.com.conf
</VirtualHost>
Por favor, observe as outras coisas que mudei:
-
dev.example.com
usa o mesmo certificado que faria sem o SNI. -
Use
<VirtualHost *:443>
em vez de_default_:443
como_default_
tem um propósito especial:Any vhost that includes the magic
_default_
wildcard is given the same ServerName as the main server.(Isto também significa que você pode usar
_default_:443
no seu "pega-tudo", não nos outros. Você pode tentar!) -
O domínio é substituído por Nomes de domínio de exemplo reservados .
-
Eu prefiro ter
www.example.com
como parte do "pega-tudo" (em vez de um alias) para ter apenas um endereço canônico para o seu site. Por isso eu mudei para lá.
Se você tiver SNI , o processamento imita o mesmo comportamento, mas é um pouco diferente em detalhes:
Before there is even an SSL handshake, Apache finds the best match for the IP address and TCP port the connection is established on (IP-based virtual hosting)
If there is a
NameVirtualHost
directive that has the same literal arguments as this best-matchingVirtualHost
, Apache will instead consider ALLVirtualHost
entries with identical arguments to the matched VirtualHost. Otherwise, SNI processing has no selection to perform.If the client sends a hostname along with its TLS handshake request, Apache will compare this TLS hostname to the
ServerName
/ServerAlias
of the candidateVirtualHost
set determined in the preceding steps.Whichever VirtualHost is selected on the preceding basis will have its SSL configuration used to continue the handshake. Notably, the contents of the certificates are not used in any comparison.
Com o SNI você pode ter o certificado adicional para dev.example.com
.
Se todos os pré-requisitos para o SNI forem atendidos, ele deverá funcionar automaticamente e error.log
mostrará [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
.