Certificate Authority problems on W2k3 server

Several bungled attempts to establish a stand-alone CA on our Windows 2003 Standard server have made a bit of a mess. We have contributed to the snafu by searching for similar problems and following the given directions and/or recommendations.

I would like to get help from someone who is a master at undoing the butchery and setting things right. It may take a lot of back and forth to root out the bad bits, so I've maxed the points on this, but I am hoping to avoid a lot of competing suggestions. Too many cooks have already spoiled this soup.

We don't believe we need an Enterprise CA, as we will be using this for Exchange OWA access internally and for VPN-connected remote users. Perhaps in the near future we will open a firewall port for SSL access.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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:
There's a good chance I can help you out - PKI is what I do for a living.  What's the actual issue here?

If you are just looking for a couple of server certs you probably don't even need to set up a CA.  You can get free server certs from startcom.org that will do the trick for you.  If your Exchange is 2007 or newer then drop a few bucks on a SAN cert from GoDaddy (under 100 bucks).  If Exchange is 2003 or older then use a startcom cert.  Both are included in the Microsoft root certificate program and the root programs of a number of other products like firefox, safari, etc.

I'm about to head out for the night, but will check in tomorrow morning.
lanalertAuthor Commented:
The immediate problem is that we are unable to access any web services on the Exchange server. All IIS services seem to be running correctly, but if we try to open OWA with any URL that worked before  (e.g. https://webmail/owa), we get "Internet Explorer cannot display the webpage." If we use the same URL as a non-SSL address (http://webmail/owa), we get a 403.4 error, "The page must be viewed over a secure channel."

Just before this problem, we had removed the Enterprise CA role from the Exchange server (a previous "tech's" stab at the problem) and then followed another seemingly authoritative, forum-sourced procedure to set up a Stand-Alone CA on one of the AD servers. Now we have the current multi-screwup-sourced situation.

Historical note: This is Exchange 2007 running on a dedicated Win2k3 64bit member server. After the original Exchange 1-year certificate expired, some greenhorn attempts were made to solve the problem by following suggestions to use PowerShell certificate commands to generate a new certificate. There's probably some clean-up to do on this too, since, obviously, nobody here is a PKI expert.
ParanormasticCryptographic EngineerCommented:
For Exchange 2007 you want to get the SAN cert from GoDaddy.  The 70 or 80 bucks (whatever it is these days) is quickly recovered in not wasting your time rolling this out, plus rolling out the new CA cert to every client that needs to access it, which for OWA probably means mobile devices and home computers == lots of support calls from users and more stuff to configure and maintain on your end.  GoDaddy's root cert is already there for most things.  Its a public facing site (even if its not for the general public) - get a commercial cert and do it right.  That should take care of the immediate issue.

For what its worth, the CA shouldn't really be on the Exchange server since it is directly connected to the internet (plus there's just enough stuff with an Ex server as it is - why add to the mess!).  That being said - they should have directed you to install a new CA first with the old CA still up and going and migrate over to the new CA and then decom the old one once everything is happy on the new CA.

The powershell thing I'm guessing made a self-signed certificate (one issued to itself) instead of a cert request for a CA?  Self-signed certs are fine for testing one or two things, but for production they're a bad idea for a handful of reasons.

The standalone CA I don't really get.  It can work, but why you wouldn't go for an enterprise CA I'm not really sure - makes life much easier and more consistent with existing documentation on the web, not to mention infinitely more functional.  Standalones should be used for offline root CA and in rare specific other situations.

Generally I recommend putting the CA on its own machine whenever possible.  It is integral to the security of your network, and the more you realize that it can do the more you will use it.  For best security, you should have the standalone root be offline and have a 2nd CA set up as an enterprise subordinate.  Using VM is generally fine for most companies for doing this, and you can emulate a pretty decent level of security for your root CA by keeping the image on a dedicated external hard drive that is normally locked up.

Anyways, hope this helps out for now, I will check back on Monday.
Challenges in Government Cyber Security

Has cyber security been a challenge in your government organization? Are you looking to improve your government's network security? Learn more about how to improve your government organization's security by viewing our on-demand webinar!

lanalertAuthor Commented:
This is a small company, and not many people will access this from outside the LAN -- maybe 3-4 at most. We are looking at standalone not because we need to go on the cheap, but because it seemed like it might be simpler to accomplish and would meet our immediate needs.

We can do as you suggest and it is certainly within our means, but the immediate concern is to get this functioning reasonably quickly. If making what we have work is something you can help with, even if it's a band-aid until we do things right, that would be great.
lanalertAuthor Commented:
Apparantly, Paranormastic is gone for the weekend. Anybody else think we can patch things up sooner. given where we are now? I have no idea how long it will take to get a SAN cert from GoDaddy or wherever and implement that solution, and, anyway, we still may have some corrections to make before we could do that. I'll work on this over the weekend if there's help to be had.
ParanormasticCryptographic EngineerCommented:
Getting a cert from GoDaddy is usually same day.  You need to provide some basic information about your company to prove that you are them, and then they will look up your company using public records to contact you via phone (not a phone number you give them, that could go to anywhere pretending to be company x).


I'm actually being quite frank here, getting a commercial cert is the best thing to do here.  It is the easiest implementation since the root is already in most products certificate stores, and setting up a CA can be time consuming and often confusing as to what you are actually doing.  The company I work for is one of the largest LANs in the world with thousands of internally issued web server certs - we still use commercial certs for the couple hundred sites that are public facing, regardless of traffic volume or if they are intended for a few employees only or millions of customers.  It hasn't been that long since I worked for a little smartcard company of all of about 35 people, too - I know how things need to be at times for smaller companies to be cost efficient, self-reliant, and as effective as possible given little amounts of time needed to properly research the dozens of new technologies you need to roll out each year.

If you like though, I do have install guides for 2008 CA set up at my site pki101.com for setting up an offline root CA and an online subordinate CA if you really want to go for it anyways.  Its still a somewhat new site, so if the main page looks a little lacking, that's why - I'm still creating it from scratch.  However, I do my best to advise proper security in my suggestions beyond "just click next" guides that are prevalent search results - that will get your CA installed but to do it right it takes a bit more than that.


A standalone sounds easier, but it really isn't.  An enterprise CA installed on an enterprise OS (i've heard you can finally do this in standard edition for 2008 R2) will give you certificate templates.  This is where the simplicity and extensibility to the CA product comes in.  You also get autoenrollment capability then.  You can install an enterprise CA on standard ed. OS, but that only give you AD integration to ease deployment - you miss out on templates & autoenrollment.  The main installation is almost the same - that part isn't much more difficult for either type, just a little bit different in certain spots.

Even if you are not planning to do much else with the CA now, you will later once you have it - count on it (email signing & encryption, document signing, file encryption, internal web sites, and much more are possible).  It doesn't make the installation any longer to do enterprise vs. standalone and the benefits are dramatic.   Standalone CA's are usually used for offline CA's or certain situations like B2B issuances or something where AD integration doesn't come into play.

It is common, although I do not advise it personally, in smaller companies to only set up one enterprise root CA on a DC (since that may be the only server or is the best chance at an Enterprise OS license).  At the very least, I advise to set up the root on a separate box that has certificate services normally stopped, simulating an offline standalone root CA (this can be done on standard ed. OS).  The reason for this is that you cannot revoke a root CA since it is self-signed (the revocation list is signed by the CA above it, so if the top tier needs to be revoked you need to get everyone that ever trusted it to remove that trust, which makes the issue that much more public and difficult should it ever occur).  If by chance you have a smartcard, you can keep the root CA private key stored on the smart card to protect it significantly better.  The more protection you can afford the root, the better.  

Also, if you can manage to keep the CA off of the DC (and off Exchange) servers that would be a good thing. They have enough going on to not need a CA to get in the way - particularily during upgrades.  Do not install the CA on a server that is directly accessible over the internet.
lanalertAuthor Commented:
Thank you for the very thorough answer, Pananormastic. I definitely will take you advice on the GoDaddy cert. Because I support these systems remotely most of the time, I'll have to work with someone there on getting the cert, in order to meet the callback req. I'll get that started right now.

Regarding remarks in your first post -- "For what its worth, the CA shouldn't really be on the Exchange server since it is directly connected to the internet" -- if and when we go with public SSL access (direct, not over VPNs), I think the plan will be to move the OWA role to the DMZ and it will access the Exchange server on the LAN.

The Exchange server is way overpowered for what it does, and our cert needs are minimal, so if internet exposure and system load are the only reasons not to run it there, I don't think it would be a problem. We have a couple of other member servers where we could put the root and keep CA services turned off.

I have to say, there sure are a lot of varying methods, procedures and opinions, among Microsoft sites, blogs, forums and such, on how to go about this. I greatly appreciate having your guidance here. Thank you.
lanalertAuthor Commented:
Regarding my first post of 4/16, and the problem as described, does it sound like setting up a CA, stand-alone or enterprise, is going to solve the immediate problem? I'm concerned that we need to fix the botched attempts before setting up a new CA.
ParanormasticCryptographic EngineerCommented:
Part of the reason to have a dedicated box for a CA is that the name doesn't need to change then.  When you install certificate services, the name of the box is tied into the database and, by default, the certificate filename.  DC's and exchange tend to be some of the more common boxes to get migrated to new boxes over time and hence are more likely to undergo name changes.  

Also, as I mention, DC's and Exchange servers tend to be some of the more touchy systems in any given environment and if you need to do a full system restore on on of these, the added headache of figuring out what to do with the CA and reissuing certs, etc., can add to the headache of an already critical and often complicated troubleshooting and restoration situation.

Technically, as long as you can maintain the alias of the original box then you can migrate the CA to another machine.  There is no real technical reason you cannot do this, but there are practical reasons to not.  As mentioned, as long as the server is on the LAN then the primary security concern is met.

>> there sure are a lot of varying methods
This is why I am starting my own site :)  In my personal opinion, most of the install guides out there are junk and should only be used in a test lab.  I've been posting here on EE and occasionally on MS forums for about 1.5 years now and have been working with PKI for about 6 years now (2.5 in a high security PKI), and I figure with all the typing I do I should spread some of my experience - I just like to help out when I can.

Another good resource are the PKI blogs from Technet, particularily Spat's PKI blog - he does an excellent job at explaining a wide variety of things, but many of these are more directed towards higher level issues to get more out of your CA.  Last, but certainly not least, would be Brian Komar's book for either 2003 or 2008 (they're both excellent) - this is currently the best published resource out there for MS CA.

Either standalone or enterprise should do the trick, I would generally advise going the enterprise route - you'll be much happier with the functionality (again, you get extra features if also installed on enterprise OS).

To get rid of the self-signed certs, you can just remove them from whatever GPO, etc. that you deployed.  On the originating machine you can open Certificates MMC (local computer) and it will probably be under Personal - Certificates - open that up and just delete it (you can export it with the private key just to be safe).

For decommissioning a previously atempted CA, I would recommend backing it up first (unless nothing ever got issued from it).  I have a section dedicated on how to do that on my site.  This is 'just in case' you find something out later.  Afterwards, here is the main article to go through for decommissioning a CA from AD:
(if the CA was already uninstalled, skip to step 6)

lanalertAuthor Commented:
>> "Part of the reason to have a dedicated box for a CA is that the name doesn't need to change then."

Yes, I remember the pain we had to go through when upgrading the servers from NT. The company's major application, developed in-house, had server names hard-coded into it. Fun times.

How about putting the root cert on a virtual server that stays off? Seems like that's about as easy as it can get to never have to change the name, and essentially no hardware cost for the dormant server.

Since I'm  trying to get educated on this, the referrals to authoritative resources are much appreciated. I'm usually pretty good at sifting through the chaff when looking for answers on the net, but this stuff is cryptic, and having a "how hard could this be?" mindset hasn't helped.

One of the articles we used when removing the Enterprise CA was: http://support.microsoft.com/kb/555151/en-us 
-- apparently an earlier version of the one you gave. Nothing of consequence was ever issued from the CA, so no concerns there.

We've got approval to go ahead on the GoDaddy cert. I figure we'll get a 3-year UCC 5-license Standard, in case another need comes up. That will be purchased tomorrow morning.
ParanormasticCryptographic EngineerCommented:
>> How about putting the root cert on a virtual server that stays off?
If you have the resources to do that, that is perfect.  One of my general recommendations is to keep the image for the root CA VM on a removable drive and when not in use to keep that drive locked up.   This is a relatively cheap way of emulating a high security environment with an offline root.  You can host the subordinate CA in VM also.

>> this stuff is cryptic
It deals with cryptography - its supposed to be cryptic :) (pun intended)
But seriously, there are mainly solid admins out there that just don't have the time or whatever to really sink their teeth into PKI, and it isn't as easy to pick up what you really need to know like it is for most of the other stuff out there.  Add to that a niche where most of the advisors on the web don't really understand it beyond the basis either and it gets really rough to pick up quickly the way most admins need to.

I wrote this EE article - it covers a broad base of stuff that is useful to know for when you do get to setting up your internal CA to meet the needs that it is meant to address:

lanalertAuthor Commented:
In reading back over your posts, I saw that you mentioned early on the idea of hosting the Root CA on an offline VM. And I thought I'd thunk it. I did intend the 'cryptic' pun, though. ^J^

Resources -- the virtual server for the root cert MIGHT fly, but we can't keep throwing server licenses at this, as in for a subordinate CA. Is there any difference between the Root CA and a Sub CA in regard to hostname-consistancy issues and maintaining/upgrading/replacing boxes?

If it's not too obvious, I'm still trying to justify putting at least the Sub CA on the Exchange server, which is not doing anything else -- not AD, DNS, SQL, virtualization, backup, not even file/print -- nada. Otherwise, I'll have to make the case for putting it on the only other candidate server, which is the most critical for our 24/7 operations and usually considered sacrosanct.

So as I understand it, as long as we are willing to deal with the issues mentioned above and have procedures for doing so, there should be no other conflict with Exchange and a Sub CA on the same box.
ParanormasticCryptographic EngineerCommented:
Any MS CA needs to keep the original hostname throughout its lifecycle.  If it gets moved to a box with a new hostname, the old hostname must be aliased to the new box.  Its just one of those things.  Alternatively, you can install a non-MS CA for the root that does not have the same limitations...  This is one of the things I have planned for my site coming up now that I have the 2008 install guides out there, I'm just wrapping up some advanced stuff for installing with nCipher HSM.  

If its not a rush, check back on pki101.com in a few weeks (hoping by Memorial weekend, I only get so much time and this is a bigger project) and I am hoping to have a Linux install guide for an OpenSSL and XCA root authority that could be used- everything will be using free open source software.  This will be done using the Sun VirtualBox software for the VM.

I never liked having to through a whole Windows server license at the root either - this is my answer to it.  Part of doing so is adding in specific OIDs that are going to be needed by the SubCA in order to issue the appropriate certificates, so it does get a little bit more complicated for the novice user, but I will have it totally laid out including the OS install.  This is one of the big things that I have planned for my site that is going to be very different than the 'standard' CA deployment guides out there.

otherwise, like I mentioned before, using an existing standard or enterprise edition server can work, but if its going to be online it is really worth contacting a smartcard company to store the root cert on a smartcard.  For 100 bucks or less, its totally worth it for that root private key protection.
lanalertAuthor Commented:
>> If its not a rush
Well, that's the thing. Taking the time to learn how to do this with certitude is a great goal, both for this installation and for future installs.

For this particular problem, however, the OWA was working from the inital Exchange install, but nobody was interested in using it. Now that the original certification has expired, they want it yesterday.

We really were hoping to get things running by the beginning of this week. The techie perfectionist in me is all on board with using the best approach, but when I started this question I imagined having help to patch things up and get functional again as quickly as possible.

If you know how to flip the bits to accomplish that, it would really take the heat off. We still plan to go the full route, but we'd love to be able to take the time to be sure it's done right.
ParanormasticCryptographic EngineerCommented:
The commercial cert should take care of your immediate worries.  For Exchange you normally need additional names in the cert, so you need a SAN cert to accomplish that, which the best deal for those is godaddy.  For other servers that may come up in the meantime, you can probably use a standard SSL cert from startcom.org - they're free (startcom is the only free public CA that is in the MS root certificate program).  Most servers just need their servername or alias in the cert and they're good to go.  That should alleviate most of the urgency, I would hope, until you get a chance to roll out your own CA.

Otherwise, for the time being I would say to roll out a root CA on an MS server and eat the license - that is was is normally done today by most companies.  The article I'm writing for linux will be a while to publish as there is a bit that goes into that due to customization to make it work in an MS environment - I've done it before just my documents are more random notes.  I've got a bit of that "do it right" too, and I wouldn't want to direct you in the wrong way.  Unfortunately I have normal work and such to do as well, so I only get a little bit of time each week to work on my site since it is at this point a hobby than a profitable venture.

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
lanalertAuthor Commented:
From your posts it seems you might have a few other things on your mind ;-)  No worries, I appreciate all the information and advice that you have offered. It is slowly dawning on me what a vast topic this is, yet in scratching the surface I've already found other reasons why we need an Enterprise CA in this particular case.

As to the immediate issue, I did an end-around and put a Linux-based L2TP service in the DMZ, through which the users have POP/IMAP access. Good enough for the time crunch.

I've got a thing or two other to do as well, so the CA setup will progress at a stately pace. My target is to complete it by the end of next week, by which time you definitely will have earned your 500 points. ^J^
lanalertAuthor Commented:
Paranormtastic, your recommendations and instructions are very clear and detailed. We haven't made the time to implement them yet, and so we temporarily set up a workaround to handle the issue that my original post was meant to address. Therefore, I marked 'partially' on a couple of the grading questions, but that's more about our progress than your answers.

We will be doing as you suggest, but don't want to keep this question open any longer; so, solution accepted. Thank you for your time and your knowledge.
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
Windows Server 2003

From novice to tech pro — start learning today.