System Shared Certificates

[jlasman]

Installing System Shared Secure Certificate on DirectAdmin Mini How-To
Jeff Lasman, directadmin@nobaloney.net 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

[jjma]

Jeff

Thanks for the instructions.I've tried the above but I still get the "snake oil" certificate after installing my comodo certificate, and making the changes to httpd.conf and directadmin.conf.

regards

Jon

[BigWil]

Sounds similar to a problem I was having. The ips.conf file has the virtualhost directive in there for the entire server it seems. I commented out the virtualhost in there and now all of my certs are working.

Big Wil

[jjma]

Yes that didn't work for me?

Jon

[BigWil]

Have to ask the silly question.... did you restart the Apache daemon?

Big Wil

[jjma]

Not a silly question but yes (twice + directadmin restarted) - might try reboot.

Jon

[jjma]

Still unable to get this server wide certificate to work which is holding up my development of DA as I go around and round in circles.

Even after rebooting, deleting the ssl.key ssl.prm ssl.crt ssl.crl and recreating them with only the server.crt and server.key files, creating a new certificate for the domain I am using to share the server ip with, installing the root certificate, changing pathe in httpd.conf and directadminl.conf I still get the snakeoil.dom!!!

What gives!

Jon

[Vibe]

This is great tutorial - Thank you!

I do have a question though (due to my inexperience :D ). I have set up my website as a RESELLER (e.g. www.mydomain.com) with a dedicated IP other than the host/server IP. Does it make a difference if I set up secure.mydomain.com as the ADMIN with the server/host IP?

From my understanding of your tutorial I believe the following would be correct (for my own situation):

hostserver.mydomain.com - IP #1
secure.mydomain.com - IP #1 (created by ADMIN)
www.mydomain.com - IP #2 (created by RESELLER)

My question is that I would like to have secure.mydomain.com for any https connections to www.mydomain.com. Will this be the case or will secure.mydomain.com/mydomain.com be the end result?

*** Updated Question ***

I found the DA template fix that allows both http and https to point to the public_html directory vs. using both the public_html & private_html directories (GREAT!!!).

Is is possible to set up secure.mydomain.com to point to the same public_html directory as www.mydomain.com *AND* have secure.domain.com be the server's shared SSL for all sites being hosted?

Thank you tremendously for any assistance!

[jlasman]

Only if they're all in the subdirectory path as mentioned in my previous post to another thread.

Jeff

[Vibe]

Hi Jeff,

Thank you again for the information. I have read the other thread and have a better idea about how DA handles the shared SSL cert. (For anyone that is interested, the post is HERE (http://www.directadmin.com/forum/showthread.php?s=&postid=53194#post53194)).

Take care!

Michael

[icepick]

Ok,

So the above method, how can I (the hosting company) allow all my users to use this shared cert. From what I understand there are 2 methods?

1./ http://secure.example.com/~username
2./ http://secure.example.com/userWebsite.com

The latter requiring symlinks and other things to be done?

Thanks
Barry

[jlasman]

I'm not sure of your question :( .

http://secure.example.com/~username works on one of our servers; I haven't tested it on all.

I recall that at one time DA made some changes to prevent domains from "stealing" bandwidth this way, so I'm not sure if it works on all servers or not.

It requires no linking of any kind.

To use the second example you could set up an ftp account for each user on secure.example.com, with a home page in that directory.

Jeff

[Ximmer]

I have installed the System Shared certificate succesfully and used the above information from the postings.

I can now access all my domains using the https://... it show the correct certificate and not the default one.

Next I have tried to use https:// too for the Directadmin control panel (port 2222). This failed.
The permissions are set right but the restart of the Directadmin fails. It gives the following message in the error log.
......
2006:02:22-21:00:21: error loading certificate
2006:02:22-21:01:01: error loading certificate
2006:02:22-21:01:11: error loading certificate
2006:02:22-21:01:19: error loading certificate


from /usr/local/directadmin/conf/directadmin.conf:
......
SSL=1
cacert=/etc/httpd/conf/ssl.crt/server.crt
cakey=/etc/httpd/conf/ssl.key/server.key
caroot=/usr/local/directadmin/data/users/admin/domains/secure.xxxxxx.nl.cacert
(the xxx = mydomainname)

The permissions and new files (22 febr)

ssl.crt:
total 448
lrwxrwxrwx 1 root root 19 Feb 13 19:30 0cf14d7d.0 -> snakeoil-ca-dsa.crt
lrwxrwxrwx 1 root root 16 Feb 13 19:30 5d8360e1.0 -> snakeoil-dsa.crt
lrwxrwxrwx 1 root root 10 Feb 13 19:30 82ab5372.0 -> server.crt
lrwxrwxrwx 1 root root 16 Feb 13 19:30 82ab5372.1 -> snakeoil-rsa.crt
-r-------- 1 root root 418567 Feb 12 14:16 ca-bundle.crt
lrwxrwxrwx 1 root root 19 Feb 13 19:30 e52d41d0.0 -> snakeoil-ca-rsa.crt
-rw-r--r-- 1 root root 1522 Feb 12 14:16 Makefile
-rw-r--r-- 1 root root 1386 Feb 12 14:16 README.CRT
-rw-r--r-- 1 root root 1619 Feb 22 20:30 server.crt
-r-------- 1 root root 1176 Feb 13 19:30 server.crt.backup
-r-------- 1 root root 1472 Feb 12 14:16 snakeoil-ca-dsa.crt
-r-------- 1 root root 1192 Feb 12 14:16 snakeoil-ca-rsa.crt
-r-------- 1 root root 1452 Feb 12 14:16 snakeoil-dsa.crt
-r-------- 1 root root 1176 Feb 12 14:16 snakeoil-rsa.crt

ssl.csr:
total 8
-rw-r--r-- 1 root root 926 Feb 12 14:16 README.CSR
-r-------- 1 root root 84 Feb 12 14:16 server.csr

ssl.key:
total 28
-rw-r--r-- 1 root root 1207 Feb 12 14:16 README.KEY
-rw-r----- 1 root diradmin 901 Feb 22 20:30 server.key
-r-------- 1 root root 891 Feb 13 19:30 server.key.backup
-r-------- 1 root root 668 Feb 12 14:16 snakeoil-ca-dsa.key
-r-------- 1 root root 887 Feb 12 14:16 snakeoil-ca-rsa.key
-r-------- 1 root root 668 Feb 12 14:16 snakeoil-dsa.key
-r-------- 1 root root 891 Feb 12 14:16 snakeoil-rsa.key

ssl.prm:
total 12
-rw-r--r-- 1 root root 516 Feb 12 14:16 README.PRM
-r-------- 1 root root 455 Feb 12 14:16 snakeoil-ca-dsa.prm
-r-------- 1 root root 455 Feb 12 14:16 snakeoil-dsa.prm

The effect is that DA does not run anymore, I have to change the "SSL=0" again in the configuration file and restart DA to recover.


Any ideas?

[jlasman]

Originally posted by Ximmer
from /usr/local/directadmin/conf/directadmin.conf:
......
SSL=1
cacert=/etc/httpd/conf/ssl.crt/server.crt
cakey=/etc/httpd/conf/ssl.key/server.key
caroot=/usr/local/directadmin/data/users/admin/domains/secure.xxxxxx.nl.cacert
(the xxx = mydomainname)
It's been a long time since I wrote the How-To and we do it a bit differently now.

We use these paths:
SSL=1
cacert=/usr/local/directadmin/conf/cacert.pem
cakey=/usr/local/directadmin/conf/cakey.pem
caroot=/usr/local/directadmin/conf/caroot.pem
and we copy the certificate files as shown here:
cd /etc/httpd/conf/
cp ssl.crt/server.crt /usr/local/directadmin/conf/cacert.pem
cp ssl.key/server.key /usr/local/directadmin/conf/cakey.pem
cp /usr/local/directadmin/data/users/admin/domains/secure.xxxxxx.nl.cacert /usr/local/directadmin/conf/caroot.pem
cd /usr/local/directadmin/conf
chown root:root cacert.pem
chmod 644 cacert.pem
chown diradmin:diradmin cakey.pem
chmod 400 cakey.pem
chown root:root caroot.pem
chmod 644 caroot.pem

If you'd like, try that both the changes above to the directadmin.conf file and then the commands I've posted above. Then restart directadmin and let me know if that works.

If that doesn't work please contact me privately via email (my address is below in my sig) if you'd like me to log into your server to figure it all out.

Please do NOT ever send a server password in an email.

Jeff

[Ximmer]

Great info Jeff!

That does solve the problem.
I do get the https control panel website now even if I start with the normal http on port 2222.
That is good.
Logging in works fine too.

There is an error in the error.log now (I was monitoring this file for errors....)
The IP address affected is the one from which I am logged in. Not the server.


2006:02:23-19:11:57: Can't connect to ssl!
2006:02:23-19:11:57: ->error ssl
2006:02:23-19:11:58: Didn't find two eols on the header from 82.xxx.xxx.xxx

2006:02:23-19:11:58: Error reading from 82.xxx.xxx.xxx:

[jlasman]

Years ago when I was in Air Force basic training (in the mid 1960s, btw), whenever one of us had a problem we brought it to our Training Instructor.

Invariably, he'd tell us "Sounds like you've got a personal problem. Tell it to the chaplain."

:)

In this case, ask your browser manufacturer.

Jeff

[IT_Architect]

Dumb question. What's the difference in SSL certificates? I realize there is 128 and 256 and whatever. I know that you need to have one recognized by the browsers, but some sites have different ones and they say if you you do a lot of volume then buy this one instead of that one etc. Why would that be? What's the diff between $400 at Verisign and $49 or less other places as long as the browsers recognize it?

[jlasman]

The difference between 128 and 256 is how easily it can be cracked. We probably don't have to worry much about that, and anyway most browsers today don't support 256 so the cert falls back to 128 anyway.

Why do you think they want you to buy a more expensive cert?

Because that way they can make more money.

Really.

There is a warranty, and often the higher priced the cert the greater the warranty.

But keep in mind that the warranty doesn't protect you, or anyone who uses your cert to protect their connection to your site.

The cert onlly protects a user of a counterfeit site if the browser company with the guarantee issued the cert to the counterfeit site.

Really. again.

As my 8th-grade civics teacher used to say:
"Look that up in your Funk & Wagnalls".

:)

Jeff

[IT_Architect]

Got it!. So then as far as I'm concerned, the only thing that matters to me is to get a cert that is recognized by all of the common browsers.

Thanks!

[jlasman]

That'll work.

:)

Jeff

[IT_Architect]

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.

[proimpulse]

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!

[jlasman]

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

[pucky]

Installing System Shared Secure Certificate on DirectAdmin Mini How-To
Jeff Lasman, directadmin@nobaloney.net 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.

[jlasman]

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.
[quote]Really, DA shouls have solved this problem a very very long time ago.

In the Admin panel the following should appear.

[B]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? ;)
[quote]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