Eu usarei certificados Multi-Domínio DigiCert para o seguinte:
www.example.com
example.com
sub1.example.com
www.sub1.example.com
sub2.example.com
www.sub2.example.com
etc...
Estou usando o URL Rewrite do IIS para remover o www. de todos os domínios, o que me dá:
example.com
sub1.example.com
sub2.example.com
Também estou usando o URL Rewrite para encaminhar todos os http: // para https: //.
Minhas perguntas:
- Preciso de www. certificados de domínio desde que eu estou reencaminhando para a versão reduzida do URL?
- São o www. certificados prefixados necessários para negociar a conexão SSL inicial?
Se possível, gostaria de eliminar todos os www. certs.
Editado
Para completar, adicionei os dois redirecionamentos que estou usando.
<rewrite>
<rules>
<rule name="Remove www" stopProcessing="true">
<match url="(.*)" ignoreCase="true" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^www\.(.+)$" />
</conditions>
<action type="Redirect" url="https://{C:1}/{R:0}" appendQueryString="true" redirectType="Permanent" />
</rule>
<rule name="Redirect to http" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" negate="false" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
</rule>
</rules>
</rewrite>
Obrigado ...
Atualização: efeitos colaterais indesejáveis
Depois de fazer muitos testes, descobri alguns efeitos colaterais indesejáveis ao remover o www. de URLs. Sob certas condições, um usuário verá um aviso de segurança sobre o site NÃO ser seguro, o que é muito ruim da nossa perspectiva.
URLs possíveis inseridos pelo usuário:
example.com,
www.example.com,
http: // ou https: // com example.com ou www.example.com
URL de reconfiguração desejada:
link
Diferenças entre os navegadores
O URL https: // + www.example.com/ NÃO é reescrito para o URL desejado no IE, Edge, Safari e Firefox, MAS é reescrito com o Chrome. Depois de pensar nisso por um tempo, não sei ao certo por que o Chrome permite a reescrita do HTTPS, já que uma URL HTTPS codificada foi inserida.
O Chrome direciona https: // + www.example.com/ para https: // + example.com. Nenhuma falha de certificado é exibida para o usuário.
Corrupção do cache do IE?
Depois de inserir o URL https: // + www.example.com no IE, parece corromper o cache do histórico.
Se você inserir www.example.com depois de inserir o URL anterior, o navegador será direcionado para https: // + www.example.com/. Isso produz uma mensagem de certificado BAD, o que não é bom.
O IE pode ser fechado e reaberto e a anomalia continua, se você entrar novamente em www.mydomain.com.
Se eu limpar manualmente o cache do URL https: // + www.example.com incorreto e, em seguida, inserir www.example.com, o IE encaminhará para https: // + example.com, que é o resultado desejado.
Corrupção do Cache Temp do Safari?
Eu consegui demonstrar uma falha semelhante no MAC Safari para as mesmas condições de teste que usei para o IE, mas o Safari se recuperou depois de navegar para outras URLs e voltar OU fechando / reabrindo o navegador. / p>
Conclusão para nosso modelo de uso
Eliminando o www. não é uma boa opção.