Esta página fornece orientações para configurar o HTTPS nos seus servidores, incluindo etapas a seguir:
- Criar um par de chaves públicas/privadas RSA de 2048 bits.
- Gerar uma solicitação de assinatura de certificado (CSR) que incorpore a chave pública.
- Compartilhando a CSR com a autoridade de certificação (CA) para receber uma versão final um certificado ou uma cadeia de certificados.
- A instalação do certificado final em um local não acessível pela Web, como
/etc/ssl(Linux e Unix) ou onde o IIS exigir (Windows).
Gerar chaves e solicitações de assinatura de certificado
Esta seção usa o programa de linha de comando openssl, que vem com a maioria sistemas Linux, BSD e Mac OS X, para gerar chaves privadas e públicas e uma CSR.
Gerar um par de chaves públicas/privadas
Para começar, gere um par de chaves RSA de 2.048 bits. Uma chave mais curta pode ser quebrada ataques de força bruta e chaves mais longas usam recursos desnecessários.
Use o seguinte comando para gerar um par de chaves RSA:
openssl genrsa -out www.example.com.key 2048
Isso gera a seguinte saída:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Gerar uma solicitação de assinatura de certificado
Nesta etapa, você incorpora sua chave pública e informações sobre sua organização
e seu site em uma solicitação de assinatura de certificado, ou CSR. O openssl
solicita os metadados necessários.
Executando o seguinte comando:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Produz o seguinte:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Para garantir a validade da CSR, execute este comando:
openssl req -text -in www.example.com.csr -noout
A resposta será semelhante a esta:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Enviar a CSR a uma autoridade certificadora
Diferentes autoridades certificadoras (CAs) exigem que você envie suas CSRs para elas de maneiras diferentes. Isso inclui o uso de um formulário no site ou o envio o CSR por e-mail. Algumas CAs, ou seus revendedores, podem até mesmo automatizar alguns ou todos do processo, incluindo, em alguns casos, par de chaves e geração de CSR.
Envie a CSR para a CA e siga as instruções dela para receber o arquivo final. ou cadeia de certificados.
CAs diferentes cobram valores distintos pelo serviço de atestado para a chave pública.
Há também opções para mapear sua chave para mais de um nome DNS, incluindo
vários nomes diferentes (por exemplo, example.com, www.example.com, example.net,
e www.example.net) ou "caractere curinga" nomes como *.example.com.
Copie os certificados para todos os seus servidores front-end em uma janela não acessível
local como /etc/ssl (Linux e Unix) ou onde o IIS (Windows) exigir
para resolvê-los com rapidez.
Ativar HTTPS nos servidores
A ativação do HTTPS nos seus servidores é uma etapa essencial para proporcionar segurança suas páginas da Web.
- Use a ferramenta de configuração de servidor do Mozilla para configurar seu servidor para HTTPS suporte.
- Teste seu site regularmente com o certificado da Teste e garantia do servidor SSL terá pelo menos A ou A+.
Neste ponto, você deve tomar uma decisão operacional crucial. Escolha uma das opções seguinte:
- Dedicar um endereço IP exclusivo para cada nome de host que seu servidor da Web veicula conteúdo se originou.
- Usar hospedagem virtual baseada em nome.
Se você estiver usando endereços IP diferentes para cada nome do host, será possível dar suporte HTTP e HTTPS para todos os clientes. No entanto, a maioria dos operadores de sites usa e hospedagem virtual para economizar endereços IP e porque isso é mais conveniente em geral.
Se você ainda não tem o serviço HTTPS disponível nos seus servidores, ative-o agora sem redirecionar o HTTP para o HTTPS. Consulte Redirecionar HTTP para HTTPS para mais informações). Configure seu servidor da Web para usar os certificados comprados e instalados. Você pode encontrar a configuração do Mozilla gerador úteis.
Se você tiver muitos nomes de host ou subdomínios, cada um deles precisará usar o nome correto certificado.
Agora, e regularmente durante todo o ciclo de vida do seu site, verifique se o HTTPS de configuração com a Qualys' Teste de servidor SSL. Seu site deve ter uma pontuação A ou A+. Trate tudo o que gera uma nota mais baixa como um bug e continue diligente, pois novos ataques contra algoritmos e protocolos estão em constante desenvolvimento.
Tornar relativos os URLs internos do site
Agora que você está disponibilizando seu site em HTTP e HTTPS, os elementos precisam funcionar como da forma mais tranquila possível, independentemente do protocolo. Um fator importante é usar URLs relativos para links intrasite.
Os URLs internos e externos do site não podem depender de um protocolo específico.
Use caminhos relativos ou não inclua o protocolo, como em //example.com/something.js.
Como exibir uma página que contém recursos HTTP usando HTTPS podem causar problemas. Quando um navegador encontra uma página segura usando recursos não seguros, ele avisa os usuários de que a página não é totalmente seguro, e alguns navegadores se recusam a carregar ou executar a solicitação recursos, o que quebra a página. No entanto, você pode incluir HTTPS recursos em uma página HTTP. Para mais orientações sobre como corrigir esses problemas, consulte Como corrigir conteúdo misto.
Seguir links baseados em HTTP para outras páginas no site também pode fazer downgrade da
de HTTPS para HTTP. Para corrigir isso, faça com que os URLs internos do site
o mais relativo possível, tornando-os relativos a protocolo (sem uma
do Cloud, começando com //example.com) ou relativos a host (começando com apenas
o caminho, como /jquery.js).
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Atualize seus links com um script, não manualmente, para evitar erros. Se as site está em um banco de dados, teste seu script em uma cópia de desenvolvimento do no seu banco de dados. Se o conteúdo do seu site tiver apenas arquivos simples, teste o script em uma cópia de desenvolvimento dos arquivos. Enviar as alterações para produção somente após para que as mudanças avancem no controle de qualidade, como de costume. Você pode usar o script de Bram van Damme ou algo semelhante para detectar conteúdo misto no site.
Ao vincular a outros sites (em vez de incluir os recursos deles), não altere o protocolo. Você não tem controle sobre o funcionamento desses sites.
Para facilitar a migração de sites grandes, recomendamos URLs relativos a protocolo. Se você não tiver certeza se já pode implantar totalmente o HTTPS, forçar seu site a usar HTTPS para todos os sub-recursos poderá dar errado. Provavelmente haverá um período em que o HTTPS é novo e estranho para você, e o site HTTP ainda precisa funcionar melhor do que nunca. Com o tempo, você vai concluir a migração e bloquear o HTTPS. Consulte as próximas duas seções.
Caso seu site dependa de scripts, imagens ou outros recursos fornecidos por um terceiro como CDN ou jquery.com, você tem duas opções:
- Use URLs relativos a protocolo para esses recursos. Se o terceiro não veicular HTTPS, peça que ele faça isso. A maioria já tem, incluindo o jquery.com.
- Disponibilize recursos de um servidor que você controla, que oferece e HTTPS. Essa é muitas vezes uma boa ideia, porque assim você terá melhor sobre a aparência, o desempenho e a segurança do site e não têm controle confiar em um terceiro para manter seu site seguro.
Redirecionar HTTP para HTTPS
Para instruir os mecanismos de pesquisa a usarem HTTPS para acessar seu site, coloque um
link canônico do arquivo
cabeçalho de cada página usando tags <link rel="canonical" href="https://…"/>.
Ative a segurança de transporte estrita e os cookies seguros
Neste ponto, você está pronto para "bloquear" o uso de HTTPS:
- Use HTTP Strict Transport Security (HSTS) para evitar o custo dos erros 301 redirecionamento.
- Sempre defina o flag "Seguro" nos cookies.
Primeiro, use a Strict Transport Security
para informar aos clientes que eles devem sempre se conectar ao servidor usando HTTPS, mesmo
ao seguir uma referência http://. Isso evita ataques como
Remoção de SSL
e evita o custo de ida e volta do 301 redirect que ativamos
Redirecionar HTTP para HTTPS.
Para ativar a HSTS, defina o cabeçalho Strict-Transport-Security. Página HSTS do OWASP
tem links para as instruções
para vários tipos de software de servidor.
A maioria dos servidores da Web oferece um recurso semelhante para adicionar cabeçalhos personalizados.
Também é importante garantir que os clientes nunca enviem cookies (como no autenticação ou preferências do site) por HTTP. Por exemplo, se o plano de um usuário cookie de autenticação fosse exposto em texto simples, sua garantia de segurança da sessão inteira é destruída, mesmo que você tenha feito todo o resto certo!
Para evitar isso, altere seu aplicativo da Web para sempre definir a sinalização segura nos cookies conjuntos Esta página do OWASP explica como definir a flag segura. em várias estruturas de apps. Cada framework de app tem uma maneira de definir o flag.
A maioria dos servidores da Web oferece um recurso simples de redirecionamento. Usar o 301 (Moved Permanently)
para indicar aos mecanismos de pesquisa e navegadores que a versão HTTPS é canônica,
e redirecione os usuários de HTTP para a versão HTTPS do site.
Classificação daesquisa
O Google usa HTTPS como uma qualidade positiva de pesquisa indicador. O Google também publica um guia sobre como transferir, mover ou migrar no site, mantendo a classificação de pesquisa. O Bing também publica diretrizes para webmasters.
Desempenho
Quando as camadas de conteúdo e de aplicativo estiverem bem ajustadas (consulte Steve Souders livros para orientação), o TLS restante as questões de desempenho geralmente são pequenas em relação ao custo total para o aplicativo. Você também pode reduzir e amortizar esses custos. Para orientações sobre TLS do Google, consulte High Performance Browser Networking, Ilya Grigorik, bem como de Ivan Ristic Manual do OpenSSL e SSL e TLS à prova de bala.
Em alguns casos, o TLS pode melhorar o desempenho, principalmente como resultado da realização de alterações HTTP/2 possível. Para mais informações, consulte Chris Palmer's sobre o desempenho do HTTPS e do HTTP/2 Chrome Dev Summit 2014.
Cabeçalhos de referência
Quando os usuários seguem links do site HTTPS para outros sites HTTP, os user agents não envie o cabeçalho Referer. Se isso for um problema, há várias maneiras de resolvê-lo:
- Os outros sites precisam migrar para HTTPS. Se os sites de referência concluírem
seção Ativar o HTTPS nos servidores de
este guia, você pode mudar os links em seu site para os outros usuários de
http://parahttps://ou use links relativos a protocolo. - Para solucionar diversos problemas com os cabeçalhos Referer, use o novo Padrão da política do referenciador.
Receita de anúncios
Os operadores de sites que monetizam sites mostrando anúncios querem ter certeza de que
a migração para HTTPS não reduz as impressões de anúncios. No entanto, devido à abordagem
questões de segurança de conteúdo, um <iframe> HTTP não funciona em uma página HTTPS.
Os operadores de sites não poderão migrar para HTTPS até que os anunciantes façam uma publicação usando HTTPS
sem perder receita de publicidade. mas até que os operadores de sites migrem para HTTPS,
os anunciantes têm pouca motivação para publicar HTTPS.
Você pode começar o processo de quebrar esse impasse usando anunciantes que que oferecem serviços de anúncios por HTTPS e que os anunciantes que não veiculam HTTPS em todos para, pelo menos, torná-lo uma opção. Talvez seja necessário adiar a conclusão Torne os URLs internos do site relativos até que haja um número suficiente de anunciantes interoperem corretamente.