Da minha experiência, quando migramos nossa hospedagem, precisamos migrar nosso SSL também. Basta obter a chave .pfx e configurá-la no seu novo provedor de hospedagem. Se não configurarmos o SSL no novo servidor, os https não funcionarão.
Nós (minha empresa) trocamos recentemente nossos servidores de nome de GoDaddy para Amazon. Nossos sites permanecem hospedados no GoDaddy. Antes de mudar de nome, tudo funcionou bem.
Temos um site, https://example.com , que redirecionará para https se foi originalmente inserido como http . Temos um segundo site que está localizado em example.com/second e resolve em https://second.com . Isso funciona da mesma forma que o primeiro site que redireciona para https de http solicitações.
Agora que mudamos os servidores de nomes, https não resolve mais. Se eu for para http://second.com/non-http-part que não requer o redirecionamento, funcionará. Mas indo para o índice onde ele redireciona, resulta na página não carregando nada. Todos os https://example.com também não carregam.
Contactamos a Amazon e eles concluíram que é um problema com os arquivos .htaccess . Isso parece estranho para mim porque soa mais como um problema de DNS, mas essa não é minha área de especialização, então posso estar completamente errado.
Abaixo está o nosso arquivo .htaccess .
rewriteengine on
rewritecond %{HTTPS} off
rewritecond %{HTTP_HOST} ^www.example.com$ [OR]
rewritecond %{HTTP_HOST} ^example.com$
rewriterule ^(.*)$ "https\:\/\/example\.com\/$1" [R=301,L]
#---[SITE PASSWORD PROECTION]
#AuthName "Restricted Area"
#AuthType Basic
#AuthUserFile /home/some_user/public_html/example/includes/security/.htpasswd
#AuthGroupFile /dev/null
#require valid-user
#---[CENTRALIZED REQUESTED]
<IfModule mod_rewrite.c>
RewriteBase /
</IfModule>
#---[OPTIONS AND ERROR DOCUMENT HANDLING]
Options -Indexes
IndexIgnore *
Options +FollowSymLinks
ErrorDocument 400 /index.php
ErrorDocument 401 /index.php
ErrorDocument 402 /index.php
ErrorDocument 403 /index.php
ErrorDocument 404 /index.php
#---[DENY ACCESS TO SPECIFIC FILES]
<FilesMatch "^(config\.php|\.htaccess|\.htpasswd|\.log|php\.ini|php5\.ini|readme\.html)">
Deny from all
Allow from 127.0.0.1
</FilesMatch>
rewritecond %{REQUEST_FILENAME} !-f
rewritecond %{REQUEST_FILENAME} !-d
rewriterule . /index.php [L]
Da minha experiência, quando migramos nossa hospedagem, precisamos migrar nosso SSL também. Basta obter a chave .pfx e configurá-la no seu novo provedor de hospedagem. Se não configurarmos o SSL no novo servidor, os https não funcionarão.
Mesmo que seu cenário seja difícil (afinal, é apenas um problema acessar um site HTTPS), as coisas são um pouco mais complexas. Vou lhe dar uma ajuda (esperançosamente detalhada) para o processo de solução de problemas.
Vamos começar com isso: " ... Se eu for para o link que não exige o redirecionar, funciona ... "
Isso sugere que a resolução de DNS para "second.com" está funcionando bem. De qualquer forma, eu iria verificá-lo diretamente, com um utilitário como host ou dig . Isso é necessário para garantir que seu sistema não está contando com algum arquivo "hosts" que possa apontar para outros endereços além dos DNS. Além disso, ignora completamente os problemas de cache do DNS local.
Aqui abaixo, você pode ver um exemplo:
verzulli@tablet-damiano:~$ host serverfault.com
serverfault.com has address 190.93.246.183
serverfault.com has address 190.93.247.183
verzulli@tablet-damiano:~$ dig serverfault.com
[...]
;; QUESTION SECTION:
;serverfault.com. IN A
;; ANSWER SECTION:
serverfault.com. 194 IN A 190.93.247.183
serverfault.com. 194 IN A 190.93.246.183
;; AUTHORITY SECTION:
serverfault.com. 90428 IN NS cf-dns02.serverfault.com.
serverfault.com. 90428 IN NS cf-dns01.serverfault.com.
[...]
;; Query time: 63 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 6 09:15:13 2015
;; MSG SIZE rcvd: 199
verzulli@tablet-damiano:~$
Agora, temos a certeza de que o DNS do qual seu sistema local depende está sendo resolvido corretamente.
Agora, verifiquei o caminho HTTP, garantindo que nada entre o sistema local e o servidor da Web remoto esteja atrapalhando a conexão HTTP. Isso pode ser típico nos contextos transparent-proxies . Observe que estou assumindo que seu navegador está acessando a Web diretamente, sem nenhum proxy explícito configurado. Se este não for o caso, por favor, dê detalhes.
Então eu verificaria se o endereço IP externo do seu sistema (aquele que você pode ver acessando, com seu navegador, sites como este ) é o mesmo que o relatado no log de acesso do servidor apache (executando corretamente). No meu caso eu recebo:
aaa.bbb.ccc.ddd
aaa.bbb.ccc.ddd - - [06/Jun/2015:09:36:35 +0200] "GET / HTTP/1.1" 200 3650 "-" "[...]"
Então, agora sabemos que ao acessar o site HTTP, vamos diretamente para o servidor da Web (ou, melhor, sem um intervalo entre eles facilmente detectável).
Agora podemos prosseguir com o teste HTTPS. Eu não sei se você tem acesso interativo ao seu sistema remoto, então eu não tenho certeza se você pode executar um tcpdump nele, então vamos ficar com a verificação de log (como eu tenho certeza que você tem acesso ao seu log arquivos). Eu:
Se nada aparecer no LOGS, do que - supondo que seu servidor HTTPS está registrando corretamente - podemos supor que há um problema na conexão SSL entre seu navegador e seu servidor.
Se a linha LOG estiver presente, podemos afirmar que o seu navegador atingiu corretamente o servidor HTTPS.
Em ambos os casos, mais ajuda pode ser obtida pela "Developer Tool" do seu navegador (o Chrome / Chromium e o Firefox têm o recurso integrado e podem ser executados com o CTRL-SHIFT-I). A Developer Tool pode rastrear todas as atividades de rede registradas pelo navegador (consulte a "Rede" TAB), incluindo solicitações HTTP / HTTPS e respostas relacionadas. Com ele, você também deve ver o REDIRECT na resposta HTTP, apontando para URL HTTPS, definido em suas regras .htaccess .
Uma observação final: nos casos em que o navegador tiver problemas para estabelecer a conexão HTTPS com o servidor HTTPS (e, como tal, nada sairia das Ferramentas do desenvolvedor), você poderá tentar uma verificação de nível inferior com openssl c_client , como em:
openssl s_client -connect your.remote.https.site:443
O comando acima mostrará todo o handshake SSL, incluindo todos os detalhes sobre o certificado do servidor, e o levará a um prompt invisível, aguardando seus métodos HTTP comuns (GET, POST, etc., como em "GET /" ).
Infelizmente, não posso fornecer mais detalhes. Se você ainda tiver problemas, forneça informações sobre os resultados das verificações acima.