1

We (my company) recently switch our name servers from GoDaddy to Amazon. Our sites remain hosted on GoDaddy. Before switching name servers, everything worked fine.

We have a site, https://example.com that will redirect to https if it was originally entered as http. We have a second site that is located at example.com/second and resolves at https://second.com. This works the same as the first site that redirects to https from http requests.

Now that we have switched nameservers, https no longer resolves. If I go to http://second.com/non-http-part that doesn't require the redirect, it works. But going to the index where it does redirect, results in the page not loading at all. All of https://example.com does not load either.

We have contacted Amazon and they have concluded that it's an issue with the .htaccess files. This seems strange to me because it sounds more like a DNS issue, but this isn't my area of expertise, so I could be completely wrong.

Below is our .htaccess file. 

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]
Chris
  • 111
  • 2
  • 3
    "This seems strange to me because it sounds more like a DNS issue" If HTTP is working and HTTPS is not, it's not a DNS issue. What's the **actual** domain name in question? – ceejayoz Jun 03 '15 at 16:03

2 Answers2

0

From my experience, when we migrate our hosting, then we need to migrate our SSL too. Just obtain .pfx key and then setup it on your new hosting provider. If we dont configure SSL on new server, the https wont work.

Mark Spencer
  • 124
  • 1
0

Even tough your scenario might looks simple (after all it's only a problem accessing an HTTPS site), things are a bit more complex. I'm going to give you some (hopefully detailed) help for the troubleshooting process.

Let's start from this: "...If I go to http://second.com/non-http-part that doesn't require the redirect, it works..."

This suggests that DNS resolution for "second.com" is running fine. Anyway, I would check it directly, with an utility like host or dig. This is needed to guarrantee that your system is not relying on some "hosts" file that could point to addresses other than DNS ones. Also, it completely bypass local DNS cache issues.

Here below you can see an example: 

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:~$

So now we're sure that the DNS your local system is relying on, is resolving correctly.

Now I'd check the HTTP path, ensuring that nothing in-between your local system and remote web-server is mangling the HTTP connection. This could be tipical in transparent-proxies contexts. Please note that I'm assuming your browser is accessing the web directly, with no explicit proxy configured. Should this be not the case, please give details.

So I'd check if the external IP address of your system (the one you can see by accessing, with your browser, sites like this) is the same as reported in the access-log of the (correctly performing) apache server. In my case I get:

  • My external IP: aaa.bbb.ccc.ddd
  • access log: aaa.bbb.ccc.ddd - - [06/Jun/2015:09:36:35 +0200] "GET / HTTP/1.1" 200 3650 "-" "[...]"

So, now we know that when accessing the HTTP site, we go straight to the web-server (or, better, with not an easily detectable mangling in-between).

Now we can proceed with HTTPS test. I don't know if you have interactive access to your remote system, so I'm not sure you can run a tcpdump on it, so let's stick to log-checking (as I'm sure you have access to your log files). I'd:

  • open the browser
  • access your not-running HTTPS URL
  • check if web-server LOGS reports the proper log line

If nothing appears in the LOGS, than --supposing your HTTPS server is logging correctly-- we can assume there's a problem in the SSL connection between your browser and your server.

If the LOG line is present, than we can state that your browser has properly reached the HTTPS server.

In both cases, more help can be obtained by the "Developer Tool" of your browser (Chrome/Chromium and Firefox have it built-in and can be launched with CTRL-SHIFT-I). The Developer Tool can track all the network-activity registered by the browser (see the "Network" TAB), including HTTP/HTTPS requests and related response. With it you should also see the REDIRECT in the HTTP response, pointing to HTTPS URL, defined in your .htaccess rules.

A final note: in cases where your browser has problems establishing the HTTPS connection with the HTTPS server (and, as such, nothing would came out from the Developer Tools), you can try a low-level check with the openssl c_client utility, as in:

 openssl s_client -connect your.remote.https.site:443

Above command will show all the SSL handshake, including all the details about the server certificate, and should lead you to an invisible prompt, waiting for your common HTTP methods (GET, POST, etc., like in "GET /").

Unfortunately, I'm unable to give you further details. If you still have troubles, please provide infos about results of above checks.

Damiano Verzulli
  • 3,948
  • 1
  • 20
  • 30