Buying an SSL certificate for Remote Web Workplace use - advice about "reissuance"

I am thinking about buying an SSL certificate to install on my SBS 2003 server, for use when I connect using Remote Web Workplace (I'm presently using a self-signed cert but its frankly embarrassing seeing the certificate error in front of my clients!).

I'm a little confused as to what the SSL company calls "reissuance". As I only need an entry level cert, should I buy one that comes with "unlimited reissuance", or can I just buy the cheaper one and just save a copy of the certificate somewhere?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ParanormasticCryptographic EngineerCommented:
Reissuance is if they need to reissue the certificate.  This is common to have for the first 2-4 weeks or so, but after that if you need your cert reissued then you need to pay for a new cert, or a discounted rate for reissuance.

The reasons you would normally need a cert reissued:
1) Initially corrupted certificate - this is obvious up front within minutes and will normally be reissued for free.

2) "Windows did it" corrupted certificate - certs are files and hence are just as likely as everything else to fall victim of Windows corrupting them.  This usually does not happen, but can at a rate similar to any other specific file.  This can happen anytime, but typically later into the life of the server.  You'll probably need to pay for this to get reissued unless you backed up the cert and private key to a .pfx file (read: export your cert from Certificates MMC including the private key to back it up to a .pfx file... and then copy/move that .pfx somewhere else to archive).

3) You screwed up the cert request - after issuing and installing you realize you should have issued to the alias instead of the server name, to the FQDN instead of the hostname, vice versa, you had the wrong key strength, or that you just simply had a typo.  Depending on how long it took you to realize this, you'll probably be able to replace for free.  (read: make sure to install and test your cert within a couple days after you buy it)

4) Private key compromise - this is rare, but since taking proper care of things tends to get expensive it can happen if someone hacks your server and accesses the directory with the private key.  Now you can't trust it, so you need to revoke it.  Expect to get charged for this.  If this is a concern, look into generating the private key on an HSM (note these are very expensive even for the cheap ones) to provide the best protection against attackers.

5) You need to reissue under a different root certificate from that vendor.  Many of the big cert vendor names (Verisign, Comodo, etc.) own many roots both under their own name and under the names of the various companies that they have purchased over the years.  Due to this, there can be occasional compatibility issues that they may be able to take care of by reissuing the cert under one of their other roots instead of the primary one for whichever type of cert you are looking at.  Again, with timely testing this is normally included in the original couple weeks that they all offer.

Reissuance is important from the cert vendor during the first few days, maybe weeks.  After that it is a safety net for those that don't know how to backup their certificate and private key properly (which isn't all that difficult, you just need to know to do it, which many admins don't somehow).  As you suspected, you can just back it up, archive it, and be a good admin.

Its just a marketing thing.  When you have a policy that screws people that is universal in the industry, then there is a place for a new service to cash in on.  I'm sure there are those that would argue otherwise, but I personally feel that this is legitimate - it is not the CA's job to secure your server and protect the key, it is yours - and each time they need to revoke the old one which makes their CRL grow, slowing things down for everyone eventually, one grain of sand at a time, not to mention the extra bandwidth and other related real costs.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ParanormasticCryptographic EngineerCommented:
As a side note, I recommend having a couple flash drives, they're getting cheap enough now, and securing them in a sealed envelope for each server - one for onsite, one for offsite (as a minimum).  Since these will have the private key, it is recommended to not store the .pfx on the server and only archive on offline media like the flash drives.  Also control access to these fobs - keep them locked up in a drawer, safe, or something.  It is best to have a separate pair of fobs for each server, but realistically this is not normally necessary - they are very small (@ 1-2 kB) so pretty much any size will suffice for many servers.  If you have a larger admin team you may wish to split off by job type (unix vs. windows, web servers vs. non-web servers, etc.).
CSHTechAuthor Commented:
Thank you for your time and effort on this - it's much appreciated.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.