https > https port 2222 redirect

R

Ramsy

Verified User
Joined
Dec 25, 2005
Messages
60
Location
London, UK
Hi,

What I would like to see is for users with SSL enabled in their account, but who haven't purchased a valid SSL certificate yet to be redirected to the main server URL with a valid SSL certificate when they try to login to https://www.clientdomain.tld:2222
This gives a certificate error.

ssl_redirect_host only works for non-SSL redirects.

Thanks.
 
Actually, youre right. I just tried a random domain on a box (maybe it works if the domain matches the hostname?) and it doesn't redirect with httpS... How weird.

So, yeah, a bug or request
 
Peter Laws said:
force_hostname=
ssl_redirect_host=

both should be the same.
Click to expand...


I didn't know about force_hostname. I re-defined it in directadmin.conf and redirecting is working for me. But, I need confirm SSL cert before, because hostnames don't match:

Code: 
https://any-hosted-domain.com:2222/ => Confirm SSL => Redirecting to https://ssl-cert-domain.com:2222/
 
Ok, you're right, maybe its how SSL works?

Thing is, people get in a panic about certificate warnings - I would.
 
I'm not sure, if it's possible to redirect a user to a proper hostname, just before SSL cert verification. But I guess it's not possible. SSL questions in some circumstances make me crazy, so somebody else can clarify the situation.
 
Hello,

If they connect with https first to the wrong domain, that's what the browser will use for the cert check. It should work if they connect to the wrong domain with just http.

The other option would be to use the bind_address option on an IP where no other domain, except your valid host) use the IP. This would completely prevent them from using the wrongdomain.com... in which case they would have to know which to use.

Ultimately, all of the redirects are only there as reminders for Users if they forgot to use ssl, or the there is a specific name to use with SSL... If they keep on getting redirected to the same value, the hope is, eventually, they'd go straight to it (but I understand that this doesn't always happen)

So bottom line, if they start with https on the wrong domain, it won't work.. they'll get a cert warning. Can't do much about that since the SSL handshake is done before the http request is even made.

John
 
Hi, I also got a valid certificate for the server-url and use this for all users to log into DA.

However, last night a user sent 500 emails, and he got an automatic email saying he got a message abt him reaching the email limit.
Below in that message was the wrong URL: https://users-domain.com:2222

Which of course brings my user to a "invalid certificate page", and he called me asking if this was a spam/hack attempt -_-;


Question: how can I change DA messages to use the domain set in "force_hostname" or "ssl_redirect_host" ?


the message they receive said:
New Message: Warning: 500 emails have just been sent by user21


A new message or response with subject:

Warning: 500 emails have just been sent by user21

has arrived for you to view.
Follow this link to view it:

https://user-domain.com:2222/CMD_TICKET?action=view&number=000011232&type=tick
et
Click to expand...
 
Followup to the text below: It seems to be a problem with the browser. The redirection does not occur before the browser freaks out due to the certificate not being for the correct domain. If mydomain.com has the same ip as the main server the browser first checks the certificate and the redirection only occurs after one accepts moving to the unsecure site. Sigh.

Original question
I cannot make this work using the directives/settings. I have my domain (say, for example acme.com) which has an SSL certificate just for the domain (no www.acme.com, ftp.acme.com etc). This is an affordable but adequate certificate I purchased for three years and it does not include the "www" part in it (neither ftp or any other, of course).

https://acme.com:2223 works as it should and I have told my customers (and a reseller) to use that one. But you know people. They keep typing in https://www.acme.com:2223 and freak out because of the warnings. Yesterday I gave a customer the correct address and told him to type it EXACTLY as I had written it. He still complained about seeing a warning. It turned out he had "just in case" added the www part. Sigh.

So the problem is that I have so far been unable to find a a way to redirect/force DA from https://www.acme.com:2223 to https://acme.com:2223.

So is it possible in any way or do I really have to buy another certificate for this sole purpose?
 
Last edited:
mkniskanen said:
Followup to the text below: It seems to be a problem with the browser. The redirection does not occur before the browser freaks out due to the certificate not being for the correct domain. If mydomain.com has the same ip as the main server the browser first checks the certificate and the redirection only occurs after one accepts moving to the unsecure site. Sigh.

Original question
I cannot make this work using the directives/settings. I have my domain (say, for example acme.com) which has an SSL certificate just for the domain (no www.acme.com, ftp.acme.com etc). This is an affordable but adequate certificate I purchased for three years and it does not include the "www" part in it (neither ftp or any other, of course).

https://acme.com:2223 works as it should and I have told my customers (and a reseller) to use that one. But you know people. They keep typing in https://www.acme.com:2223 and freak out because of the warnings. Yesterday I gave a customer the correct address and told him to type it EXACTLY as I had written it. He still complained about seeing a warning. It turned out he had "just in case" added the www part. Sigh.

So the problem is that I have so far been unable to find a a way to redirect/force DA from https://www.acme.com:2223 to https://acme.com:2223.

So is it possible in any way or do I really have to buy another certificate for this sole purpose?
Click to expand...

This is a feature, not a bug. The entire point of SSL/TLS here is that you -first- validate the request, and only after that you can redirect and do other HTTP stuff. It is impossible to bypass it, otherwise SSL/TLS would be broken.
 
nielsh said:
This is a feature, not a bug. The entire point of SSL/TLS here is that you -first- validate the request, and only after that you can redirect and do other HTTP stuff. It is impossible to bypass it, otherwise SSL/TLS would be broken.
Click to expand...

Yes, that is exactly what I wrote in my followup and I noticed there is nothing one can do about it. So the only thing to get rid of the warning when redirecting from www.acme.com:2223 to acme.com:2223 is to have a certificate that serves both addesses.

Lesson learned. And the behaviour is actually a good thing just as you said.
 
You must log in or register to reply here.
Back
Top