DA login over SSL with single IP and SNI enabled, possible?

Z

zmippie

Verified User
Joined
Apr 19, 2015
Messages
164
Hey there,

I've been reading these forums for a long time, gathering truly invaluable info. But I'm stuck with a tricky issue for which I can't find a solution.

I have a VPS running DA with just one IP address. I've set it up with SNI enabled (enable_ssl_sni).

But I also have set up DA to allow only secure (https) authentication at login as per this tech note.

Now this works nicely for the server itself, with the server certificate:

https://server.com:2222

But I want each user to be able to log into DA (using their own certificate (which I require for all users), not the server's) on their own domain name. For example:

https://userdomain1.com:2222
https://userdomain2.com:2222

I can't seem to make it happen. A domain name mismatch certificate error comes up, because apparantly, the certificate presented at login is the server's, not the user's (which makes sense somehow, the user certificate hasn't been specifically installed for DA, like the server cert).

The automatic redirect from plain text to a secure connection to DA, through ssl_redirect_host=host.name.com as is explained here, will only redirect to a single host name.

Am I overlooking something, or am I expecting just a little too much from the SNI SSL-setup? Or is it just a DA limitation?
 
I get it, I think

Thanks for your swift reply, Alex. I ordered a multi-domain certificate for one of the user accounts, but now I think what you're trying to say is: one certificate for my admin account *and* all users together. Wow, haven't thought of that. But then, I didn't realize until yesterday that you can add and/or modify a multi-domain certificate and have it reissued. Otherwise, I'd have to (re)buy the entire multi-domain certificate each time I added a user. But this indeed might work. I'm going to give it a try.

I'll report back with my findings.
 
Close, but...

Well, thanks to Alex pointing me in the right direction, I've got things working pretty much the way I wanted to. I have a multi-domain certificate in which I intend to incorporate all the domains for different users. Re-issuing will be a pain, but I'm not planning on many users, so hopefully it won't be so bad.

I can log into each different DirectAdmin user panel on each domain name over SSL, and the certificate is accepted for each domain.

But... there's one thing I'd like to solve, and that is the certificate "hostname mismatch" error I'm getting when I type:

http://adomainname.com:2222

...in order to log into DirectAdmin. Note that it's the non-secure login, which I've disabled. I'm not sure why it barks here, giving me a redirect to the IP address of the server if I ignore the warning. I'd like it to automatically redirect to https://adomainname.com:2222 but as far as I can see (and mentioned in my initial post) that can only be done for one domain.
Is there a way to mod_rewrite the DA-login, or is Apache not involved (I'm thinking not, because if httpd is down, you can still log into DA)?

Any thoughts?
 
It's working, sort of...

Strange, I've created this reply yesterday, but it never showed up. I don't quite get how this forum works I guess. Is it human-moderated for new users?

Anyway, thanks to Alex pointing me in the right direction I now have a multi-domain certificate that allows me to log into DA over SSL on different domain names:

https://domain1.com:2222
https://domain2.com:2222

But there's still something quirky going on when I use plain text HTTP:

http://domain1.com:2222

This gives me a certificate host name mismatch warning from my browser and then, if I choose to continue, sort of redirects (there is no HTTP redirect) to the IP address to log in. Is this to be expected?

Now a redirect to https:// would be the solution, but as I said in my initial message, this can only be done to a single domain.

Am I expecting too much from this setup?
 
As a variant you can set directadmin to port 2221 and use ssl_port=2222:

Code: 
port=2221
ssl_port=2222

in this case nobody will access directadmin via HTTP, unless you open it in your firewall.
 
zEitEr said:
As a variant you can set directadmin to port 2221 and use ssl_port=2222:
in this case nobody will access directadmin via HTTP, unless you open it in your firewall.
Click to expand...

Hmmm... that looks quite clever, but I can't seem to make it work. Should a restart of DirectAdmin be sufficient have this option take effect? I'll give it another try.

Thanks.
 
Yes, a restart is all what you need to do after you modified directadmin.conf.
Probably there is a process running which does not die with restart. Try to

Code: 
killall -9 directadmin
/etc/init.d/directadmin start


and then check:

Code: 
netstat -ntpl | grep directadmin
 
No dice

Thanks again for the suggestion zEitEr,

zEitEr said:
and then check:

Code: 
netstat -ntpl | grep directadmin
Click to expand...

I'm getting:

Code: 
tcp        0      0 :::2221                     :::*                        LISTEN      27414/directadmin   
tcp        0      0 :::2222                     :::*                        LISTEN      27416/directadmin

So that works. Unfortunately, the browser gets redirected to the IP address if I try http://mydomain.com:2222, just like before. I think this isn't going to work. Other suggestions welcome.
 
zmippie said:
Unfortunately, the browser gets redirected to the IP address if I try http://mydomain.com:2222, just like before. I think this isn't going to work. Other suggestions welcome.
Click to expand...

If to consider ssl_redirect_host= it redirects only from http, not from https.

I don't get redirected if I use https://domain.com:2222/ even if I get ssl_redirect_host=server.domain.com

Hmm, I've tested myself:

And even with:

Code: 
port=2221
ssl_port=2222

the panel is accessible with http://domain.com:2222/ and yes here is where the redirect happens. Well, that's not really what I was thinking.

Well in this case I only could suggest that you use NGINX or lighttpd to proxy requests to Directadmin. I don't offer apache as apache is serving sites, and it might be down, and even so you still can use it. A web server can easily differentiate http and https requests.
 
zEitEr said:
the panel is accessible with http://domain.com:2222/ and yes here is where the redirect happens. Well, that's not really what I was thinking.
Click to expand...

zEitEr, no it's not that easy to get it to work like I want it. But maybe I should just forgo my attempt, and accept the servername redirect. I see this with a lot of shared-hosting parties too. It's a cosmetic thing, but to me that's important, even if it's just for learning purposes.

zEitEr said:
Well in this case I only could suggest that you use NGINX or lighttpd to proxy requests to Directadmin.
Click to expand...

That would be an interesting challenge to set up. I have NGINX running on the server, so maybe I'm already halfway. But there's more stuff to do/try to get this server set up to my needs, so I'll put this one on the backburner. Thanks for the suggestion though.
 
SeLLeRoNe said:
Thats look to me like an IPv6 listening actually...

Are you using IPv6 on your server? If not, have you disbaled it?

Regards
Click to expand...

SeLLeRoNe, no IPv6 addresses are tied to this server (yet). Would it matter in this case? Thanks.
 
Getting back to this thread after two months:

I've configured DA to do the HTTPS redirect to the server domain. It would be nice if DA provided an SNI-option to allow HTTPS on any domain, but alas (yes, that was a cryptic attempt to a feature request :rolleyes:)

But now when users log in to DA, the "Webmail"-button in the DA user interface will open the webmail on the server domain (and there is none, so it ends in a 404). It should, of course point to the main domain of the current user. So there you are, another feature request.
 
You must log in or register to reply here.
Back
Top