6 replies to this topic

[RHochstenbach]

I've designed a web application which runs on HTTPS using a valid SSL certificate. At the first page I'm doing an IP check to allow only access from specific IP addresses. When an IP address has been successfully validated, I use the header("location: nextpage.php") function to send users to the next page. This works fine, but when using Internet Explorer (version 8), visitors get a message about an untrusted website and the URL bar is not green (meaning that the browser does not detect the SSL certificate). But when I click on a link directly to that 2nd page or when I use JavaScript to redirect users to that page, it works fine without issues. All other web browsers don't seem to be having this issue.

Is this caused by the header function? And if so, is there a known workaround for this issue?

[Alexander]

It is likely that IE is being correct in sending you to page.php, but through a non-HTTPS transport. This is due to the fact that you are telling the browser to view "nextpage.php" and not explicitly giving it an HTTPS address.

Try to use full resource addresses instead https://domain/path/nextpage.php in all location headers.

Manual relative addresses are different, the browser "fills in" the scheme://domain/path portion based on the current address - it does not do this for a location header.

Alexander.

[RHochstenbach]

Alexander said:

It is likely that IE follows specification a little too closely, and sends you to a non-HTTPS transport which contains HTTPS content (embedded images for example) breaking authentication.

Try to use full resource addresses, explicitly defining https://domain/path/nextpage.php in all location headers.

Manual relative addresses are different, the browser "fills in" the scheme://domain/path portion based on the current address - it does not do this for a location header.

Alexander.

I've tried that, but it doesn't make any difference (made sure to clear the browser cache first before testing again).

[Alexander]

RHochstenbach said:

I've tried that, but it doesn't make any difference (made sure to clear the browser cache first before testing again).

I would need more information on what breaks the authentication. Did you buy SSL for www.domain.com and are linking to domain.com instead? Do images come from somewhere that is not certified? There must be a difference.

[RHochstenbach]

I've checked that the domain name (www.domain.com) for which I purchased the certificate is correct. All external files are stored on the server and are being accessed with https. The only difference is that it uses the header() function. Using a redirect from JavaScript and clicking on a link to that page both work fine. That's why I'm confused :)

Could it have something to do with the fact that the redirect is launching too fast?

[bbqroast]

Perhaps IE doesn't recognise the certificate authority? Can you hit a "I understand the risks (not recommended)" button? Trust me Chrome thinks every SSL site is bad (won't even let me use gmail.com, mail.google.com works thou).

[RHochstenbach]

bbqroast said:

Perhaps IE doesn't recognise the certificate authority? Can you hit a "I understand the risks (not recommended)" button? Trust me Chrome thinks every SSL site is bad (won't even let me use gmail.com, mail.google.com works thou).

In that case I don't know why it does recognize it when opening the page directly. It's signed by Comodo.