HOWTO - Viewing KEYs and CRTs in WHM

[trakwebster]

*** HOWTO about Viewing SSL certs in WHM's SSL Manager ***

In WHM, there is an SSL section. Unless you're a reseller on the server (ie: not root), there is a selection in WHM called 'SSL Manager'. It is not completely obvious how to read the information shown there, so the purpose of this HOWTO is to simply clarify what is being shown.

The SSL Manager displays three columns of information: Keys, CSRs, and CRTs. First, for newbies, let's be very clear what these three things are. (I, at least, found these terms confusing at first.) Definitions of these three abbreviations are:

(a) KEY: the encryption KEY which will stay secret on the server;

(b) CSR: the Certificate Signing Request (CSR) that you made up to send off to verisign or InstantSSL or other Big Flapdoodle Authority along with some money so they would send you the part you really need, which is the ...

(c) CRT: the CeRTificate (CRT) which you give out publically to any browser.

Remember, the CSR was just an 'application form' you sent along with money. The two parts that do the work are the private KEY which you made for your server to use, and the public CRT (certificate) which the Big Flapdoodle Authority made for you for all the browsers to use.

So that is KEY (for your server) and CRT (certificate) for visitor's browser. Or, even simpler:

KEY for you; CRT for them.

Each of these things, the KEY and a CRT, is really just a textfile containing bunch of characters that say nothing to a human. However, to your server and the visiting browser, they are secret decoder rings so they can talk to each other in secret code.

Back to SSL Manager ...

When you look in the SSL Manager there are three columns, labled KEYs (for you), CSRs (application forms), and CRTs (for visitors). In my SSL Manager, nothing currently appears in the CSR (application forms) column, so all we have to think about is the KEY and the CRT column.

Here's how SSL Manager displays the information:

First, know that it just looks in the /usr/share/ssl/private folder, and it finds all the KEY files there. For example, suppose that you have two customers with keys (www.prettyboy.com.KEY and www.uglyguy.com.KEY ) and suppose that you have your key for the server itself (biggie.server.com.KEY). So, finding these things, SSL Manager will display them in the left column labled KEYs.

So far, so good. But suppose that you've reinstalled one or more of these keys for prettyboy or uglyguy or for your handsome server. In that case, there might be an '.old' key in there also. And during the installation process, either the system or WHM runs a test, and this creates a '.test' version of the key, and that's in there also. So your KEYs column might say:

www.prettyboy.com.key
www.prettyboy.com.key.old
www.prettyboy.com.key.test

www.uglyguy.com.key
www.uglyguy.com.key.old
www.uglyguy.com.key.test

biggie.server.com.key
biggie.server.com.key.old
biggie.server.com.key.test

And they probably won't look all neat like this but may be all jumbled up.

Next, you would think that the SSL Manager would look in the corresponding /usr/share/ssl/certs folder, and list all the '.CRT' files. But that's not exactly the way it lists them. Instead, on the same line as each of the '.key' entries, it lists the *corresponding* '.crt' file which matches.

To be sure, these .crt files are indeed found in the corresponding /usr/share/ssl/certs folder, but realize that a single .crt file is going to be listed multiple times, because it's the matching file for several of the .key entries.

Now, elsewhere we have a great forum HOWTO about cleaning up your WHM, and what it says, in short, is to go to the /usr/share/ssl/private folder, and delete all the .old and .test entries. (If you're the cautious/paranoid type, like me, you maybe make a folder and transfer them in there, just to make sure things still work OK!) After you have got rid of the .key.old and .key.test files, if you'll look in WHM's SSL Manager, you'll see that it's much easier to read! In the KEYs column, it will now say:

www.prettyboy.com.key
www.uglyguy.com.key
biggie.server.com.key

For a human, that's much clearer. And also, where previously you saw www.prettyboy.com.crt listed three times in the CRTs column, now it's only listed once, because there is now only one www.prettyboy.com.key which it matches.

Important note #1: There are some other files in /usr/share/ssl/certs and /usr/share/ssl/private folders. For example, 'ftpd-rsa-key.pem' and 'imapd.pem' and 'Makefile'. Leave all these files alone!

Inportant note #2: In the CRTs column, you may also see some 'ca-bundle' files for prettyboy and uglyguy and your server. Some Big Flapdoodle Authorities (Verisign) that charge a lot of money don't need no stinkin ca-bundle files; so if you paid the big bucks, no ca-bundle files were needed. Other Big Flapdoodle Authorities that charge less money will require the ca-bundle files so they will be there. I'll not be explaining ca-bundle files here, except to say that you may, or may not, see some in the CRTs column of SSL Manager.

However, even with these additional files appearing along with the KEY and CRT entries, you should now find that it's easier to view the SSL Manager with clarity.

-- Arthur Cronos from Voltos

[gemininetcom]

attn: trakwebster
============

i am a newbie regarding cpanel and ssl thru whm and was reading your article with interest, as we are having problems using up2date with RHN.

while using WHM 8.5.1 cPanel 8.5.3-S3 RedHat 9 kernel 2.4.20-24.9 - WHM X v2.1.1, we recently changed from Demo to Upgrade Entitlement at RedHat.

While in Demo mode we did a couple of kernel updates without problems. But as soon as we switched to Update mode, up2date starting crashing due to GPG signature verification failure.

using your info, we checked :
(1)
SSLCertificateFile /usr/share/ssl/certs/ca-bundle.crt <- OK
(2)
SSLCertificateKeyFile /usr/share/ssl/private/............. <- no key found !!!!!

ssl manager display following info:
KEYS: ftpd-rsa-key.pem
CSRS: -nil-
CRTS:
ftpd-rsa.pem
Makefile
ca-bundle.crt
ftpd-dsa.pem
imapd.pem
ipop3d.pem
make-dummy-cert

*****

WHM (for us) and cPanel (for accounts) access thru https://domainname:2087 and https://domainname:2083 are working fine

QUESTIONS:
(1)
re. RHN up2date: since we went to Update entitlement - do we need to purchase another (i.e. additional) ssl solely for RHN in order to run up2date
(2)
adding new ssl on server-level: could it screw up proper working of WHM and cPanel

tks/cu
robby

[trakwebster]

Hi, Robby,

First, I'm no big expert. I worked out the post above somewhat laboriously, and that was a long time ago.

However, until somebody who knows more comes along, I'll take a crack at a couple of your questions. Pleae bear in mind that I'm not altogether knowledgeable about several of the things you mentioned.

First, GPG signature verification probably has to do with a "signature" code embedded in whatever you are downloading. The GPG (or PGP or MD5) are ways to guarantee that the file you're getting is from who you *think* it's from.

So firstly I'd guess that GPG signature verification failure has nothing to do with the Security Certificates or Keys on your system.

Nextly, I don't know anything at all about Demo mode or Update mode. I don't even what that is.

I thought that up2date was closed down by RedHat as of 12/31/03 for all RedHats except version 9. Maybe you have version 9.

I'd suggest one of several things to track down the source of your difficulty --

1) If you have any support from RedHat, they'll know.

2) If you don't have any support from RedHat, they've got a pretty good "search" facility on their site, and you might find a solution, or at least a better definition of what's going wrong.

3) If you have a cpanel license, either your host (if you have one) or cpanel will probably respond to a trouble ticket.

4) Keep asking on these forums, and you'll find somebody that knows more than I do.

Good luck, and may fee Thorce be with you.