SSL not working to login to Control Panel - Port 2222

aodat2

Verified User
Joined
May 9, 2006
Messages
38
Hi guys,

Was just wondering if anyone has any idea about what is going on with my SSL.

When I try to go to the login page via https, it will always give me "ERR_SSL_PROTOCOL_ERROR". It does not matter which of my website I am actually doing it for, it will always give this error. However I could easily login without the SSL.

I've tried to check the error.log but there is nothing there about this.

I've basically migrated from the Old Server to a New Server so the install for DirectAdmin is basically a fresh install and is on CentOS 8. Everything was restored from the User Backup (if that matters).

But I have a domain which I use for testing and have basically created a totally NEW account for it and have used the free Let's Encrypt SSL and yet the same problem happens. I just am unable to connect via SSL to the Control Panel page.

Would appreciate it if anyone can shed some light on what I should do next.

BTW, I have done what is written here as well:

Not sure what else I could do to resolve this issue. Hope that someone can help me on this. It's not a huge issue as it happens only for DirectAdmin but it's still something I need to resolve sooner or later.

NOTE: SSL on the website works totally fine. No problems at all.

Thanks in advance for the help and feedback.
 

Attachments

  • error2.png
    error2.png
    9.9 KB · Views: 10
Did you add ssl=1 to the config file? And restart directadmin process?
 
Did the cacert.pem cakey.pem, carootcert.pem get created in the /usr/local/directadmin/conf/ directory? Did you confirm that ssl=1 is still in the directadmin.conf file?
 
Have just noticed that SSL is not set to 1 so I just changed it.

Now instead of that error, it is giving me "ERR_CONNECTION_REFUSED".

Hahaha... Nothing in logs.
 
Please look also if the cert is for al parts you need for that domain

So if www then with www if also non www then should be also non www.

If port 2222 DA you should look for the hostname cert and da script for that and hostname shouldn't be domain.

so for server this hostename:2222 is something like server.domain.example:2222

You links to docs are for hostname so not the domainname!!! is using port DA 2222
 
Please look also if the cert is for al parts you need for that domain

So if www then with www if also non www then should be also non www.

If port 2222 DA you should look for the hostname cert and da script for that and hostname shouldn't be domain.

so for server this hostename:2222 is something like server.domain.example:2222

You links to docs are for hostname so not the domainname!!! is using port DA 2222
Sorry but kinda confused...

What should I do now? Since it is giving me "ERR_CONNECTION_REFUSED" on all the domains which is on the server. It doesn't matter which domain I try to access, it still gives the same error.

I mean after changing from SSL=0 to SSL=1, then everything is giving me that error. Even without SSL, it will not allow me into the Control Panel now.
 
Also for hostname:2222 so not domainnames! ?

IN help link you posted:
NOTE The hostname value, eg: your.hostname.com must match the "servername" value set in the directadmin.conf, or it will not be in hostname mode, but User domain mode instead.


hostename:2222 is something like server.domain.example:2222

if that is done right then all users can login DA there over that link. Later yu can with readings and so look if you can solve this for the user domains , but first things first it should work on hostname:2222
 
Last edited:
OK, let's just say my hostname is server.domain1.com.

I already installed a Wildcard SSL for domain1.com so it doesn't matter what the hostname might be, it should work.

Plus if I try https://www.domain1.com/ it works totally fine. If that's the case then https://www.domain1.com:2222/ should not be a problem or server.domain1.com should not be a problem as well.

So... I'm not too sure what else should be done already.

Ps. I have set back SSL=0 so that everything is working. If SSL=1, then it doesn't matter if SSL or non-SSL, you cannot get into the Control Panel at all.
 
is this working? so for hostname itself
server.domain1.com:2222


something with wildcard for server hostname there are lot here in forum and help and docs info about what to do to yes or no have problems i can't help with that.

port 2222 is not a default where certs are on that is port 443 and some for mail / ftp and so , handled is different from that

This is (old) for hostname more.... https://help.directadmin.com/item.php?id=645

If newer docs and where i don't know!
 
is this working? so for hostname itself
server.domain1.com:2222
Without SSL = yes
With SSL = no

For /usr/local/directadmin/conf/directadmin.conf
SSL=0

If If /usr/local/directadmin/conf/directadmin.conf
SSL=1

Nothing works at all.
 
Without SSL = yes
With SSL = no
So then it is wrong configured in base somewhere take a look in links and docs

as said the wildcard i can't help but don't know this is working yes or no for hostname, there are situations that this is not working sofar i know.
 
I already installed a Wildcard SSL for domain1.com so it doesn't matter what the hostname might be, it should work.
You're certainly wrong there. A wildcard SSL does -NOT- include the hostname.

So if you did not create a certificate for your hostname you won't be able to visit it via hostname SSL anyway, it's different.
Just create one:
cd /usr/local/directadmin/scripts ./letsencrypt.sh request_single server.domain.com

Next to SSL=1 also letsencrypt=1 should be present and enable_ssl_sni=1 and ssl_redirect_host=server.domain.com (hostname) in directadmin.conf and user only lowercase. So if one of those is missing, add it and restart directadmin. Good chance a rewrite_confs (from the custombuild directory) is also necessary after this.

Edit: fixed some typo's.
 
You're certainly wrong there. A wildcard SSL does -NOT- include the hostname.

So if you did not create a certificate for your hostname you won't be able to visit it via hostname SSL anyway, it's different.
Just create one:
cd /usr/local/directadmin/scripts ./letsencrypt.sh request_single server.domain.com

Next to SSL=1 also Letsencrypt=1 should be present and enable_ssl_sni=1 and ssl_redirect_host=server.domain.com (hostname) in directadmin.com. So if one of those is missing, add it and restart directadmin. Good chance a rewrite_confs (from the custombuild directory) is also necessary after this.
Will try it again... update in a few minutes.
 
Oke, I just editted my post, please remind to use lowercase text in the directadmin.conf file for letsencrypt=1 because I'm not sure if it matters, but normally that is lowercase. SSL=1 is indeed uppercase.
 
Oke, I just editted my post, please remind to use lowercase text in the directadmin.conf file for letsencrypt=1 because I'm not sure if it matters, but normally that is lowercase. SSL=1 is indeed uppercase.
ok, I guess it is working now.

My quick question is (if you can explain)...

Example my server hostname is server1.domain.com
I have a domain on the server which is domain.com

When I create the SSL and all, it should be able to be used, right? But it seems that nothing is working if I do that.

Now I have changed the hostname to server1.anotherdomain.com

Then I basically followed (below)
You're certainly wrong there. A wildcard SSL does -NOT- include the hostname.

So if you did not create a certificate for your hostname you won't be able to visit it via hostname SSL anyway, it's different.
Just create one:
cd /usr/local/directadmin/scripts ./letsencrypt.sh request_single server.domain.com

Next to SSL=1 also letsencrypt=1 should be present and enable_ssl_sni=1 and ssl_redirect_host=server.domain.com (hostname) in directadmin.conf and user only lowercase. So if one of those is missing, add it and restart directadmin. Good chance a rewrite_confs (from the custombuild directory) is also necessary after this.

Edit: fixed some typo's.

But shouldn't server1.domain.com also work? Why do I need to change my hostname to server1.anotherdomain.com?

That's where I am really confused.

Another thing is why should I need to use ssl_redirect_host? I mean, previously you don't have to use that (older software) and you can just directly use it without the redirect thingy. So here is another question where I have. What's the reason for the redirect?
 
Last edited:
But shouldn't server1.domain.com also work? Why do I need to change my hostname to server1.anotherdomain.com?
That confuses me too, because that should indeed not be necessary if server1.domain.com is configured as hostname both in the OS and Directadmin.
If you request a hostname certificate with the ./letsencrypt.sh request_single server1.domain.com command it should just work.
We also have names like domain.com for domain name and using server1.domain.com as hostname without a single issue.

The only thing to understand is that a wildcard certificate only works on domain and subdomains, but not on hostnames, at least not in Directadmin.

If I'm not mistaken, the ssl_redirect_host setting is not really a requirement, but makes things easier/nicer in any case.
it might be nicer if your customers (or yourself) are redirected to the hostname (if you use that for DA) rather than the ip address.
So you should be able to use that without the redirect setting, at least if there is a ssl certificate present for the hostname and the other settings are correct within the directadmin.conf file.
 
That confuses me too, because that should indeed not be necessary if server1.domain.com is configured as hostname both in the OS and Directadmin.
If you request a hostname certificate with the ./letsencrypt.sh request_single server1.domain.com command it should just work.
We also have names like domain.com for domain name and using server1.domain.com as hostname without a single issue.

The only thing to understand is that a wildcard certificate only works on domain and subdomains, but not on hostnames, at least not in Directadmin.

If I'm not mistaken, the ssl_redirect_host setting is not really a requirement, but makes things easier/nicer in any case.
it might be nicer if your customers (or yourself) are redirected to the hostname (if you use that for DA) rather than the ip address.
So you should be able to use that without the redirect setting, at least if there is a ssl certificate present for the hostname and the other settings are correct within the directadmin.conf file.
Actually, I tried it for hostname.domain.com first but it didn't work, so I tried wildcard and that too did not work. So that's why I am totally confused over why it did not happen.

On my old server I could easily create server1.domain.com and it would easily work but now it seems that it doesn't work. Not sure what happened and not too sure why it is such.

Further to that, I'll try to "No Redirect" thingy to see what happens. Hope it can work too. But even if it does, I will just leave it as a redirect. It's totally strange that it seems a lot has changed with so many things getting crazy.

BTW, do you have the problem of if someone disable their SSL, they are unable to turn it back on again and you will need to go in via SSH to change the value to set it back? Do you have a solution or do you know a solution for that?
 
Actually, I tried it for hostname.domain.com first but it didn't work, so I tried wildcard and that too did not work. So that's why I am totally confused over why it did not happen.
Have you added any of the other settings I mentioned, except for the ssl redirect setting? If yes, that could be the cause.
If not and it -is- working with that redirect present, then that looks like an DA bug because that should not be necessary.

It might also have to do with some changes in the LE script or DA version, I don't know. At this moment I did not configured a new server so I'm not aware of any issues with this.

Indeed you could test by removing the redirect line and restart direct admin and rewrite confs and see what happens next. If it still works then we can be sure it's not that line.

do you have the problem of if someone disable their SSL, they are unable to turn it back on again
No I'm not aware of any such problem. However, I don't have users turning off SSL themselves. I did it for a domain a couple of months ago, but at that time I was logged in as the user via my admin account.

As long as the "ssl" option is present for the user in their package, they should be able to turn it off and on again when needed.

You might try to switch that user to the enhanced skin and see if you are able to turn it on again then in the domain settings.

If yes, then it's a theme issue, if not then it's a DA bug and then the solution is to report it.
If it's a them bug, then you can report it in the theme section.
 
Back
Top