Tiny SSL issue: after checkout_success, non-SSL

[raddygast 0]

Ok, I struggled all day yesterday with getting SSL configured. I can't even remember now what the problem was -- I had images showing up non-SSL. I dug around on the forums for hours until I found that my host (1and1.com) required a slightly different syntax in catalog/includes/application_top.php (for the request_type variable).

 

That fixed everything. My Shared SSL certificate works like a charm, and osC is behaving as I'd expect it to behave. If a customer hits the site, they're non-SSL, until they go to create an account (or log in).

 

That's when I have two issues:

 

#1) After hitting my account, filling out the info, and setting up an account, when they're done that and hit submit, there is an IE popup indicating that they're being redirected to an insecure site. Of course, they're just in the catalog, so there's nothing to protect, but IE's message is always bad for business, i.e. "this may be intercepted, etc." Going to view account history or anything like that switches back to SSL.

 

#2) After making a purchase (I'm using the Paypal IPN module, but I think this happens no matter what), they are returned to osC in SSL mode (checkout_process.php I believe), and then this changes to checkout_success.php where they are told: "Thank you for purchasing!" If they hit the confirm/continue button from there (this is with that default guy on the surfboard clip-art), then there is another one of those popups, saying they're being redirected to a non-secure site (again just the catalog).

 

 

 

I don't understand this osC behaviour. Is it meant to be like this? I can fully understand browsing, adding items to the cart, etc., but once a customer LOGS IN, shouldn't it stay in SSL mode pretty much forever? I.e. until the next time they come to the site after the session is expired, and only then if they don't log in immediately.

 

I just don't understand the constant switching. Well, there may be some uses for it I'll grant, but I would rather have the site be SSL the whole time someone is logged in.

 

Is there an easy way to force this? If not, is there an easy way to just require everyone on the site to be in SSL mode, logged in or not?

 

Note: I don't have a dedicated SSL yet. Mine is shared, so that the site URL is:

 

https://ssl.perfora.net/mydomain.com/catalog

 

Any help greatly appreciated. Thanks!

[stevel 2]

In your configure.php, you want something like this:

 

define ('HTTP_SERVER', 'http://example.com');
define('HTTPS_SERVER', 'https://ssl.perfora.net/example.com');
define ('DIR_WS_HTTP_CATALOG', '/catalog/');
define (DIR_WS_HTTPS_CATALOG, '/catalog/');

If you put the https modifier on the DIR_WS_HTTPS_CATALOG, you'll get this behavior unless you make an edit to tep_redirect.

[raddygast 0]

In your configure.php, you want something like this:

 

define ('HTTP_SERVER', 'http://example.com');
define('HTTPS_SERVER', 'https://ssl.perfora.net/example.com');
define ('DIR_WS_HTTP_CATALOG', '/catalog/');
define (DIR_WS_HTTPS_CATALOG, '/catalog/');

If you put the https modifier on the DIR_WS_HTTPS_CATALOG, you'll get this behavior unless you make an edit to tep_redirect.

<{POST_SNAPBACK}>

 

Not sure what you mean by "https modifier". Your example shows your DIR_WS_HTTP_CATALOG and DIR_WS_HTTPS_CATALOG to be the same.

 

I have:

 

  define('HTTP_SERVER', 'http://www.example.com'); // eg, http://localhost - should not be empty for productive servers
 define('HTTPS_SERVER', 'https://ssl.perfora.net/example.com'); // eg, https://localhost - should not be empty for productive servers
 define('ENABLE_SSL', true); // secure webserver for checkout procedure?
 define('HTTP_COOKIE_DOMAIN', 'www.example.com');
 define('HTTPS_COOKIE_DOMAIN', 'ssl.perfora.net');
 define('HTTP_COOKIE_PATH', '/catalog/');
 define('HTTPS_COOKIE_PATH', '/example.com/catalog/');
 define('DIR_WS_HTTP_CATALOG', '/catalog/');
 define('DIR_WS_HTTPS_CATALOG', '/catalog/');

 

 

Is that incorrect for forcing SSL for logged in users?

[stevel 2]

The way you have it now is what I was recommending.

 

No, once the customer enters SSL, it does not stay in SSL forever. osCommerce drops out of SSL once the customer leaves the checkout process. Because some browsers complain if a secure page redirects to a non-secure page, tep_redirect, if it sees you are going from secure to non-secure, looks for HTTP_SERVER in the target URL and replaces it with HTTPS_SERVER. That way, the redirected target is still secure, thus avoiding the warning, but all links on that page are non-secure.

 

At least this is the way it is supposed to work...

[raddygast 0]

The way you have it now is what I was recommending.

 

No, once the customer enters SSL, it does not stay in SSL forever.  osCommerce drops out of SSL once the customer leaves the checkout process.  Because some browsers complain if a secure page redirects to a non-secure page, tep_redirect, if it sees you are going from secure to non-secure, looks for HTTP_SERVER in the target URL and replaces it with HTTPS_SERVER.  That way, the redirected target is still secure, thus avoiding the warning, but all links on that page are non-secure.

 

At least this is the way it is supposed to work...

<{POST_SNAPBACK}>

 

Ah, ok. If all links on the page are non-secure though, the lock icon would disappear, they just wouldn't get that popup warning, correct?

 

Is there any way, without all this fumbling, to change a couple of lines in a config file somewhere to force osC into SSL mode all the time? Even before a customer logs in?

 

I thought there was an .htaccess command SSLRequireSSL, but it doesn't work for me. Maybe I need a dedicated SSL cert for it, and it won't work with shared because the shared SSL certif is on a different host entirely that (I think) essentially redirects requests from it to my host.

[stevel 2]

The lock icon does not care about the links on a page, only the page itself. In the normal way of doing things, the page the customer is sent to after exiting checkout (usually index.php) would be displayed as secure, with the lock, but a click on a non-secure link after that would remove the lock.

 

Sure - you can make HTTP_SERVER be the same as HTTPS_SERVER, but I don't recommend it. The first page the customer goes to will not be secure unless you detect that and redirect it (PayPal's home page does this, for example.)

 

It really should work ok the way it is. Perhaps you can send me a PM with your store URL and I can try it myself?

[AlanR 3]

Is there any way, without all this fumbling, to change a couple of lines in a config file somewhere to force osC into SSL mode all the time? Even before a customer logs in?

<{POST_SNAPBACK}>

 

Sure, a simple change to one line in one file.

 

But I'm not going to tell you what or where because you're chasing snowflakes.

 

You don't want to be running the catalog under ssl, especially your shared ssl, all the time unless you don't give a fig about being found by search engines. Not to mention the hit in performance (speed) you'd take.

 

The behavior you're seeing, a warning by the browser is perfectly normal if the browser security settings are set to warn on such a switch.

 

The same thing would happen at any banking or credit card website or Amazon.com. Move on to more important things.

[raddygast 0]

Sure, a simple change to one line in one file.

 

But I'm not going to tell you what or where because you're chasing snowflakes.

 

You don't want to be running the catalog under ssl, especially your shared ssl, all the time unless you don't give a fig about being found by search engines. Not to mention the hit in performance (speed) you'd take.

 

The behavior you're seeing, a warning by the browser is perfectly normal if the browser security settings are set to warn on such a switch.

 

The same thing would happen at any banking or credit card website or Amazon.com. Move on to more important things.

<{POST_SNAPBACK}>

 

Thanks for pointing this out. I understand that the browser popup is more threatening than it need be -- but customers will think so as well. Now, people may be used to this, but in osCommerce it happens under weird circumstances.

 

If they were clicking on "return to catalog" or something like it, then the popup wouldn't seem so strange. But this is occuring after they finish creating an account, or after they successfully pay for something and are redirected to checkout_success. When they hit continue or whatever, it suddenly says "being redirected to an insecure site" -- which comes at a very sensitive time. Even though they're already done with the financial transaction, people might think that the details they just entered on the paypal site or whatever are being sent plaintext.

 

I know it's just a minor issue, so I will have to think about a way to solve it. But thanks for pointing out the search-engine thing.

 

I will also have to get a dedicated SSL. I just had a strange error where if I tried to checkout items without an account, and it redirected me to create one, after account creation it doesn't successfully go to checkout and gives me a 404 proxy redirect error. :(

 

$49 for Dedicated SSL it is. I'd go for one of those cheaper ones (like from godaddy) but apparently they don't have a proper trusted root and will trhow up all sorts of messages on Mac browsers.

[mi_jaiten 0]

Thanks for pointing this out. I understand that the browser popup is more threatening than it need be -- but customers will think so as well. Now, people may be used to this, but in osCommerce it happens under weird circumstances.

 

If they were clicking on "return to catalog" or something like it, then the popup wouldn't seem so strange. But this is occuring after they finish creating an account, or after they successfully pay for something and are redirected to checkout_success. When they hit continue or whatever, it suddenly says "being redirected to an insecure site" -- which comes at a very sensitive time. Even though they're already done with the financial transaction, people might think that the details they just entered on the paypal site or whatever are being sent plaintext.

 

I know it's just a minor issue, so I will have to think about a way to solve it. But thanks for pointing out the search-engine thing.

 

I will also have to get a dedicated SSL. I just had a strange error where if I tried to checkout items without an account, and it redirected me to create one, after account creation it doesn't successfully go to checkout and gives me a 404 proxy redirect error. :(

 

$49 for Dedicated SSL it is. I'd go for one of those cheaper ones (like from godaddy) but apparently they don't have a proper trusted root and will trhow up all sorts of messages on Mac browsers.

<{POST_SNAPBACK}>

Reading what you have to say reminds me of paranoia maybe you should calm down and exude a little trust. Don?t you realise that millions if not billions of people browsing a site with SSL capabilities get the same pop ups it?s just a security warning don?t take it so literally, other people don?t.

 

To quote you; ?I understand that the browser popup is more threatening than it need be -- but customers will think so as well?.

 

I feel it?s you who finds it threatening!

Do you have any proof that a majority of customers agree with you?

 

I suggest that you put an explanation to the offending pop up on your site that pops up when that one does, explain the reason for the security warning pop up express that there is no cause for concern (if it puts your mind at ease).

In addition why not place a survey on your site for your visitors/shoppers to complete as to their concerns to the pop up warning, their response is more important than your over reactions.

 

Good Calma for you. :thumbsup:

[mi_jaiten 0]

Thanks for pointing this out. I understand that the browser popup is more threatening than it need be -- but customers will think so as well. Now, people may be used to this, but in osCommerce it happens under weird circumstances.

 

If they were clicking on "return to catalog" or something like it, then the popup wouldn't seem so strange. But this is occuring after they finish creating an account, or after they successfully pay for something and are redirected to checkout_success. When they hit continue or whatever, it suddenly says "being redirected to an insecure site" -- which comes at a very sensitive time. Even though they're already done with the financial transaction, people might think that the details they just entered on the paypal site or whatever are being sent plaintext.

 

I know it's just a minor issue, so I will have to think about a way to solve it. But thanks for pointing out the search-engine thing.

 

I will also have to get a dedicated SSL. I just had a strange error where if I tried to checkout items without an account, and it redirected me to create one, after account creation it doesn't successfully go to checkout and gives me a 404 proxy redirect error. :(

 

$49 for Dedicated SSL it is. I'd go for one of those cheaper ones (like from godaddy) but apparently they don't have a proper trusted root and will trhow up all sorts of messages on Mac browsers.

<{POST_SNAPBACK}>

Reading what you have to say reminds me of paranoia maybe you should calm down and exude a little trust. Don?t you realise that millions if not billions of people browsing a site with SSL capabilities get the same pop ups it?s just a security warning don?t take it so literally, other people don?t.

 

To quote you; ?I understand that the browser popup is more threatening than it need be -- but customers will think so as well?.

 

I feel it?s you who finds it threatening!

Do you have any proof that a majority of customers agree with you?

 

I suggest that you put an explanation to the offending pop up on your site that pops up when that one does, explain the reason for the security warning pop up express that there is no cause for concern (if it puts your mind at ease).

In addition why not place a survey on your site for your visitors/shoppers to complete as to their concerns to the pop up warning, their response is more important than your over reactions.

 

Good Calma for you. :thumbsup:

[ukgoods 0]

I am having the exact same problem. I use the advanced search box in header contribution. Once you create an account and are in "locked mode", and try to search for anything, you get this warning.

 

I have an intern in for the summer. I asked them to test out our site. When they did a search and got this message, he immediately went nuts. He said in no uncertain terms that he would not shop on my site because of this. I have asked other friends about this and each of them said if they got this message, they would cease shopping.

 

I have asked multiple times and did not get an answer on how to get rid of this message. I did not understand completely what the previous post was about tep_redirect to get rid of this message.

 

Please help!

 

Donna Gordon

UKGoods.com

[raddygast 0]

Yes, I just realized now that although AlanR's point is valid, what I'd like is not to make the whole site SSL in general -- just for people who have LOGGED IN.

 

I don't want to change the definition for HTTP_SERVER, but I do want to learn where in the code I can place a simple statement to intercept requests and redirect them to the https server, *if* customer state = logged in.

 

Any help?

[stevel 2]

Please send me a PM with a pointer to your site and let me see what it does. I don't get this behavior on my store.

[stevel 2]

raddygast let me peek at his site. I found the problem but not the solution.

 

tep_redirect needs to know if the current page is SSL in order to decide if it needs to make the target page SSL as well. It does this by this test:

    if ( (ENABLE_SSL == true) && (getenv('HTTPS') == 'on') ) { // We are loading an SSL page

unfortunately, raddygast is on 1and1, whose SSL configuration, is to put it mildly, rather strange. HTTPS isn't defined. Well, that in itself is not too unusual - my own host at one time did the same (no longer does.) So a fallback test is to see if getenv('SERVER_PORT') == 443. Well, on 1and1 it is 80 for SSL pages so that doesn't work either.

 

Now it turned out that raddygast had already discovered this bit for the test in application_top.php, and had replaced it with a test involving eregi on $HTTP_HOST and seeing if it could be found in HTTPS_SERVER. You'd think that maybe $HTTP_HOST would be the shared SSL hostname, but no, it's the regular site domain name. The one saving grace is that it doesn't include the www. which HTTP_SERVER has but HTTPS_SERVER includes the domain name without the www. So this test should work. And it apparently does in application_top, but I could not get it to work in tep_redirect - kept getting a PHP error about REG_EMPTY.

 

So, I sent a PM back to raddygast explaining what I had found. I recall seeing someone say that there was a contrib or something with all the changes you needed to make for 1and1, so perhaps that's a hope.

 

I hope this helps others in this situation. I feel bad that I could not figure out how to fix tep_redirect to compensate for 1and1's bizarre configuration.

[AlanR 3]

1&1 comes in on port 80 for shared ssl. Other ssl proxy servers also use port 80.

 

Dedicated ssl on 1&1 uses port 443.

 

Here's the fix for detecting an ssl connection on 1&1 shared ssl

 

http://forums.oscommerce.com/index.php?sho...23entry672623

 

In short your line could be:

 

if ( (ENABLE_SSL == true) && (getenv('HTTP_X_FORWARDED_HOST') == 'ssl.perfora.net')  ) { // We are loading an SSL page

[AlanR 3]

Steve didn't say where the line in question is found. So for future readers it's

 

catalog/includes/functions/general.php, line 23.

[AlanR 3]

I only use a shared ssl account on 1&1 for a test server and I never noticed the issue.

 

I turned off the pop up warnings in IE long ago and I don't even have IE installed on this machine right now. Firefox doesn't have those popups. I think most people who use IE who see those warnings learn to ignore them or disable them, they're constant, osC or not. There's a disable button in the Pop Up window itself.

 

But...

 

I made the change in: catalog/includes/functions/general.php and it does indeed result in a "soft landing" into an ssl page for the create_account_success page.

 

https://ssl.perfora.net/somedomain.com/cata...unt_success.php?

[raddygast 0]

I only use a shared ssl account on 1&1 for a test server and I never noticed the issue.

 

I turned off the pop up warnings in IE long ago and I don't even have IE installed on this machine right now. Firefox doesn't have those popups. I think most people who use IE who see those warnings learn to ignore them or disable them, they're constant, osC or not. There's a disable button in the Pop Up window itself.

 

But...

 

I made the change in: catalog/includes/functions/general.php and it does indeed result in a "soft landing" into an ssl page for the create_account_success page.

 

https://ssl.perfora.net/somedomain.com/cata...unt_success.php?

<{POST_SNAPBACK}>

 

 

 

You guys are such amazing help I don't know how to thank you. Stevel, I am really grateful for the time you spent on this. I'd Paypal you a beer if that were somehow possible. :)

 

AlanR, thanks for that solution. I'll apply it right away and report back.

 

I have one question, though. Ok, two. It seems these "hacks" to get around 1and1's weirdness involve changing the "am I in SSL mode?" test. I don't really know what eregi is, but it sort of worked. Then that expression that checks for port 443 should have, in theory, completely solved the matter, but I take it the problem is that 1and1 uses port 80 for *SHARED* SSL, right?

 

So my first question is, WHEN I get a dedicated SSL, this problem will be nonexistent? (As long as I leave that eregi test there, still)?

 

Second question, WHEN I get a dedicated SSL, do I have to change any of these new fixes (by AlanR) back, or will they continue to work?

 

Basically, the shared SSL sucks. The other night I was getting weird proxy errors -- thought I had screwed something up, but then suddenly it started working on a refresh. I think the server just couldn't handle all the redirecting load. So I will change it -- I just wanted to fix this now because I'm in "testing" mode, but plan to go live in the next few days. Still lots of work to do.

 

Ok, finally, another question (I lied about two, but this is really brief). 1and1 can give me a dedicated SSL that is supposedly through GeoTrust (Equifax signing authority, not that weird subsidiary Equifax one that rapidssl uses). It only costs $49 USD for a year, so it must be some 1and1 special rate they've arranged by creating a special partnership with them.

 

The question is, I can get cheaper dedicated SSL, for about 28 bucks, through GoDaddy or BlueRazor (same company). It is a "Starfield" certificate, signed ultimately at the root level ValiCert.

 

But I read that it's crap, because on OSX (Safari, maybe even Firefox) it isn't a trusted root, so it throws up warnings. On Windows it's fine, because apparently the ValiCert thing is pre-installed into the trusted root list on PC browsers.

 

So basically, is this true about StarField being crap, and is it better to just get the GeoTrust at that decent rate?

 

Keep in mind, I anticipate many of my customers won't even give a rat's ass about SSL, or even notice. In the payment process, they're redirected to Paypal anyway, which is obviously secure.

[AlanR 3]

Here's an explanation of how the eregi test works:

 

http://forums.oscommerce.com/index.php?sho...077entry65907

 

It's kind of a flakey workaround that a guy came up with about 1 1/2 years ago and I used it for a little while.

 

But it's got a lot of pitfalls so I looked around and came up with this one, which is solid.

 

http://forums.oscommerce.com/index.php?sho...23entry672623

 

As to your other question: 1&1 dedicated ssl uses port 443 and returns a response to getenv('HTTPS') a '1'. So it's pretty much standard.

 

If you have one of the better accounts with 1&1 a dedicated ssl is included in the price. The GeoTrust one that you can add on to your account is the same and hassle free, ask them for it and it will be installed and it will work.

 

But: You will have to reverse the changes you made to accomodate the shared ssl server if you get the dedicated ssl. The solutions I've given are specific to the shared ssl proxy.

[AlanR 3]

I installed IE with full warnings turned on, poked around and it only seemed to pop up the warnings when I'd expect it to.

 

If you still think something's not right, tell me exactly where so I can check it. My version (IE 5.2 Mac) pops up warnings about going into a secure page even when you're going from one secure page to another. I think MS kind of overdid the system myself.

[raddygast 0]

I installed IE with full warnings turned on, poked around and it only seemed to pop up the warnings when I'd expect it to.

 

If you still think something's not right, tell me exactly where so I can check it. My version (IE 5.2 Mac) pops up warnings about going into a secure page even when you're going from one secure page to another. I think MS kind of overdid the system myself.

<{POST_SNAPBACK}>

 

AlanR, you and stevel are my gods.

 

I did actually find that post you had made about the myenv.php program. What a great idea -- I'm just a php newbie or I would have done that myself if I knew how.

 

Sure enough, there is no information available to differentiate http from https, except the HTTP_X_FORWARDED_HOST and HTTP_X_FORWARDED_BY, both ssl.perfora.net.

 

So I've gone back and fixed that eregi hack, to check for HTTP_X_FORWARDED_HOST=ssl.perfora.net. That goes in /catalog/includes/application_top.php

 

Then I went and fixed that bit in

 

/catalog/includes/functions/general.php

 

To use the same test.

 

My site no longer gives popups to me. Not sure why, because it still does switch from https to http mode, but now that the popups are gone it rocks.

 

My question is, what do those two changes do, and why are there two of them? The application_top one seemed to fix the fact that after a new user signs up, once they finish creating their account, and click on continue, they get the popup. Fixing application_top fixed that.

 

But I was still getting popups after a successful payment through paypal. Going back to the checkout_success page was SSL, but when they clicked continue from there they'd get the popup.

 

But now, with that fix to general.php, they don't, because they actually go to the main site page in SSL mode. Clicking on a category or product, after that, will redirect them to http. Exactly the behaviour you'd expect, and I'm happy with it.

 

So in short, it all works. I understand WHY those SSL tests weren't working, and I understand why they work now. What I don't get, really, is why two tests were necessary, and one of them seemed to govern post-account creation, while the other one governed checkout success.

 

If you check my site now, maybe there are no popups?

 

Anyway, fantastic help guys. And now onto more important things, like the heinous task of adding FIELDS to my products database. (God, I wish i could just do that through the admin CPL)

[stevel 2]

The only time you should have had a problem anyway is when clicking a button submits a form which does a redirect from a secure page to a non-secure page. In the checkout process, this would occur only after the checkout is complete and the customer clicks on Continue on the Checkout Success page.

 

You can also see the issue if the customer does a login from a normal page - after they log in, they are redirected back to the page they were on before, or the index page if osC can't figure out where they were before. In both cases, the customer is clearly not "sending personal data", so they would be unlikely to worry. I do see these warnings on big company sites, so apparently they don't worry about it either.

 

I'm glad to have helped solve the problem for you.

[AlanR 3]

My question is, what do those two changes do, and why are there two of them? The application_top one seemed to fix the fact that after a new user signs up, once they finish creating their account, and click on continue, they get the popup. Fixing application_top fixed that.

<{POST_SNAPBACK}>

The difference between the change to application_top.php and the one to general.php is that the first is major and the second minor.

 

Without fixing application_top many people end up with broken padlocks because the system fails to change the <base href="http://somedomain.com/catalog/"> line and osC will pull images via http not https.

 

Lots of servers need some tweak to application_top because the (getenv('HTTPS') == 'on') test is so narrow. GoDaddy fails that test on dedicated ssl, there's no response. 1&1 fails on dedicated ssl because it returns a 1 instead of on. Other hosts provide a variety of responses on dedicated and shared ssl.

 

The change to general.php is minor because the result of the test failing is kind of trivial. If it wasn't we'd have seen hundreds of posts seeking a solution. A server requiring the port 443 test in application_top would fail. Most IE users who visit sites with secure areas know that IE throws up a blizzard of warnings if they're enabled so they either turn the warnings off or ignore them.

[kewler 0]

I've read everything 3 or more times and tried 2 installs (one from a known good working dedicated SSL) and I cannot login with SSL.

 

My affiliate login works just fine, but I can't login to the store database.

 

It kindof acts like its working (no errors to trace) but just refreshes the page.

It works with SSL off, but for the life of me, I am stumped.

 

I made the mods to general.php and application_top.php

 

no eregi stuff.

 

Did anyone have to do any special mods to get the login stuff working or is it an artifact of caching/cookies/sessions?

 

I really want to get this SHARED SSL working on 1and1 without a GeoCert.

 

Kevin

 

Free icyball to the guy/gal that can help me solve this

 

http://thermalband.com/catalog/

 

 

The difference between the change to application_top.php and the one to general.php is that the first is major and the second minor.

 

Without fixing application_top many people end up with broken padlocks because the system fails to change the <base href="http://somedomain.com/catalog/"> line and osC will pull images via http not https.

 

Lots of servers need some tweak to application_top because the (getenv('HTTPS') == 'on') test is so narrow. GoDaddy fails that test on dedicated ssl, there's no response. 1&1 fails on dedicated ssl because it returns a 1 instead of on. Other hosts provide a variety of responses on dedicated and shared ssl.

 

The change to general.php is minor because the result of the test failing is kind of trivial. If it wasn't we'd have seen hundreds of posts seeking a solution. A server requiring the port 443 test in application_top would fail. Most IE users who visit sites with secure areas know that IE throws up a blizzard of warnings if they're enabled so they either turn the warnings off or ignore them.

<{POST_SNAPBACK}>

[stevel 2]

Strange. I can create an account, but it forgets I have done so after I did. Then when I try to log in, I get:

 

Error: SSL proxy not configured!

 

The SSL proxy service is not availabe for the requested domain.

If you are the domain owner, you can enable it through your control panel.