System Shared Certificates

I got my cert. I've tried 3 different ways from 2 different articles on the forum. I'm still looking at snakeoil. Drectadmin.conf has been edited, I found out that DA does not write my cert to the file from the interface, I have to copy it in ssh on the cert side. Copying the files around, restarting httpd and directadmin makes no difference. It's still snakeoil.
 
I am still trying to figure out how to make shared SSL work for multiple domains.

I have a cert set up on the main hosting account (new server) but it will not work like the (old server) with https://www.main-domain/~clients-user-name

It will work using the IP address like:

https://123.34.45.123/~clients-user-name
but you get a nasty error pop up that says the cert does not belong to that IP but to the main domain name.

I think the issue may be a new feature in DA but hopefully there is a simple work around for this.

I've already moved several sites over to the new server not knowing about this issue so they are all broken at this time.

Thanks in advance for your help!
 
This reply is both to IT_Architect and to proimpulse:

I've already prepared an exhaustive How-To (you're reading that thread now) that works for me and plenty of other people.

I've responded many times to these questions; for some reason whenever I see a question I blame it on my own inability to write a clear How-To and I try to help as much as I can.

I've even gone so far as to offer as a commercial product a Secure Certificate and installation service.

How much more can I do? :o

I will say this:

If the domain you use is a regular domain on your server, either created in your admin user account, or in a user in your admin reseller account or in a user created in the admin reseller account, or in either of those places for any other reseller account, with its own IP# (except for the main admin user account), and if the cert is created through the Certificate section of the user account for the domain in question, it will work.

Jeff
 
Installing System Shared Secure Certificate on DirectAdmin Mini How-To
Jeff Lasman, [email protected] 07/04/04 23:29
======================================
DirectAdmin will allow you to install a system-wide shared certificate for use by all your users and resellers to log-in, and which users and resellers may also use for their own directories inside a secure server setup, so they can run eCommerce and other secure services without having to purchase their own secure certificate.

We installed this on one server by taking the following steps, which will result in a secure server at, for example, secure.example.com (in all cases below be sure to replace the "example.com" with the name of your domain):

1) Logged in to the DA control panel as admin, we set up a domain in the user control panel, using the main server IP#. We named the domain
"secure.example.com".

2) Continuing in the user control panel for that domain, we entered the SSL Certificates area and proceeded to create a Certificate Request (CSR). You may wish to create your own self-signed certificate instead.

If you're using a self-signed certificate, you may skip the following steps concerning ordering and installing a certificate signed by a Certificate Authority, and continue to step 8.

3) When we created the CSR the DA control panel also created a Private Key, which we saved in the event of the unlikely scenario that it would somehow become overwritten. We then logged out of DirectAdmin.

4) We ordered a certificate from a Certificate Authority. Because we're Comodo resellers we ordered an InstantSSL certificate from Comodo. Because Comodo certificates are not recognized by all browsers, Comodo also issues a "CA" (chain) certificate issued for them by GTE Corporation, and recognized by most browsers.

5) When the cert arrived we logged back into the DirectAdmin control panel as admin, and again went to the user control panel, and we again entered the SSL Certificate area. We pasted the certificate that Comodo sent us immediately below the Private Key, clicked on "Paste a pre-generated certificate and key", and then clicked below, the certificate window, on "Save".

If you ordered your Certificate from a vendor that does not issue a "CA" (chain) certificate, you may skip the following steps concerning installing and linking the chain certificate, and continue to step 8.

6) Then we clicked on "Click Here to paste a CA Root Certificate", then on the next screen clicked on "Use a CA Cert" to create a checkmark, and pasted the chain certificate into the Certificate window, and clicked on "Save".

7) Because DirectAdmin doesn't make any changes to the systemwide httpd.conf file (the one found at /etc/httpd/conf/httpd.conf, we made the following changes to that file:

a) In the first secure virtual host container, the one named
"<VirtualHost _default_:443>, we searched for the line:

#SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt

and made sure that all the SSLCACertificate directives were commented
out (preceeded by a # character). The underneath the line as shown
above, we added the line:

SSLCACertificateFile
/usr/local/directadmin/data/users/admin/domains/example.com.cacert

b) In the second secure virtual host container, the one named
"<VirtualHost 67.19.117.218:443>", we searched for the line:

SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key

and added immediately below it (without commenting anything out) the
line:

SSLCACertificateFile
/usr/local/directadmin/data/users/admin/domains/example.com.cacert

8) Then as root, we restarted the httpd server, making sure there were no errors. (Warnings of nonexistent NameVirtualHosts are acceptable.)

9) To enable DirectAdministration logins using the secure server we edited the file /usr/local/directadmin/conf/directadmin.conf as follows:

a) First we edited the line "SSL=0" so it would read "SSL=1" (without
the quotes).

b) Second we edited the line beginning with "cacert=" to read the
following:

cacert=/etc/httpd/conf/ssl.crt/server.crt

c) Third we edited the line beginning with "cakey=" to read the
following:

cakey=/etc/httpd/conf/ssl.key/server.key

d) Fourth, immediately under the line beginning with "cakey=" we added
the following line:
carootcert=/usr/local/directadmin/data/users/admin/domains/example.com.cacert

10) To allow the directadmin server to read the key to secure port 2222, we changed the ownership and permissions of the server.crt, the ssl.key directory and the server.key, as follows:

chmod 644 /etc/httpd/conf/ssl.crt/server.crt
chmod 750 /etc/httpd/conf/ssl.key
chgrp diradmin /etc/httpd/conf/ssl.key
chmod 640 /etc/httpd/conf/ssl.key/server.key
chgrp diradmin /etc/httpd/conf/ssl.key/server.key

11) Finally we restarted directadmin:

/etc/rc.d/init.d/directadmin restart

While this works for shared SSL it does not solve the naggin issue of SSL logins. If the user visits http://domain.com:2222 then are redirected to the servers ip address, instead of the above cert. They go to https://ipaddress:2222 not https://secure.example.com:2222. Is that correct? Then my second question is, what is the purpose of getting a cert if your not offering shared ssl? Then in that case, you can redirect all you want, but DA will always send the user to the ip address https://ip and never to the registered SSL cert right?

Really, DA shouls have solved this problem a very very long time ago.

In the Admin panel the following should appear.

Redirection
Always redirect users to the ssl/tls ports when visiting /DA, /webmail, etc. YES/NO

When visiting /DA or /webmail WITHOUT SSL, you can choose to redirect to:
Hostname YES/NO Origin Domain Name YES/NO

When visiting /DA or /webmail with SSL, you can choose to redirect to:
SSL Certificate Name YES/NO Hostname YES/NO or Origin Domain Name YES/NO

Redirect user to the following URL upon logout of the DA interface. A blank value specifies the default logout page. ______


Matching redirect scripts would need to be included here, redirect.cgi/php or whatever, wredirect.cgi/php for webmail redirect etc.

As i see it, this is just sheer laziness on DA's part. Features like this should be included. In addtion, any change made from a control panel standpoint should be AUTOMATICALLY updated. I'm talking about, when add a SSL certificate, httpd.conf should contain the necessary entries. People should not have to rely on patching httpd.conf manually using TRIAL and ERROR.

Give me a break. Its not you Jeff, im just venting as this is way overdue.
 
Last edited:
While this works for shared SSL it does not solve the naggin issue of SSL logins. If the user visits http://domain.com:2222 then are redirected to the servers ip address, instead of the above cert. They go to https://ipaddress:2222 not https://secure.example.com:2222. Is that correct?
This is correct. It's been discussed many times on these forums.
Then my second question is, what is the purpose of getting a cert if your not offering shared ssl?
Perhaps you want a Ceritificate for hostname.example.com so your welcome email can tell your clients to log into DirectAdmin at https://hostname.example.com:2222/ and to log into webmail at https://hostname.example.com/squirrelmail/.
Then in that case, you can redirect all you want, but DA will always send the user to the ip address https://ip and never to the registered SSL cert right?If you use http:// instead of https://] and DirectAdmin is set up to use a secure cert, then yes, it will always redirect to the IP# rather than any domain name. And if your customer uses any other domain name besides the one the Certificate is issued for, the browser should always issue a warning anyway. And since you can only have one Certificate per IP#/Port# pair, this is a limitation of how a secure connection works, not of anything DA related.
Really, DA shouls have solved this problem a very very long time ago.

In the Admin panel the following should appear.

Redirection
Always redirect users to the ssl/tls ports when visiting /DA,

This already exists in the directadmin.conf file; perhaps you should post your request in the Feedback & Feature Requests subform where it can be considered.
/webmail, etc. YES/NO
See the above as to why this would result in errors unless the user had his/her own cert on his/her own IP#. My own feeling is that this is something that should be explained in a welcome email. Your mileage may certainly vary, and again, you can certainly feel free to request this in the proper subforum.
Redirect user to the following URL upon logout of the DA interface. A blank value specifies the default logout page. ______
I bet you know what I'd answer here, right? ;)
As i see it, this is just sheer laziness on DA's part.
Have you asked them for this? Has anyone else? Maybe no one sees the need for it except you? You can't blame DA staff for laziness just because you want a feature they haven't added.
In addtion, any change made from a control panel standpoint should be AUTOMATICALLY updated. I'm talking about, when add a SSL certificate, httpd.conf should contain the necessary entries. People should not have to rely on patching httpd.conf manually using TRIAL and ERROR.
I've NEVER had to change httpd.conf manually when adding an SSL Certificate; I have no idea why you do.
Give me a break. Its not you Jeff, im just venting as this is way overdue.
Well, I didn't delete your post. And I even responded to it. If you want suggestions to be considered, venting is generally not the way to get it done.

Generally the way to get it done is to request it. There's even a place in the forum to request it.

Continuing to vent here just fills a useful thread with unnecessary stuff; and since a lot of people check this thread every time a post appears herein, if the thread continues to get filled with venting that doesn't add a thing to the How-To, I'll simply close the thread.

Jeff
 
Back
Top