Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a webservice that our application uses and the developers require https connections to the webservice. Since this is an internal webservice would you use a self signed cert?

share|improve this question

Rather than a self-signed cert I'd create a local root CA and then generate the SSL cert from that, ensuring that all internal systems have a copy of the root CA'sl public key.

Keys generated this way have plenty of uses outside of plain HTTPS, they can also be used for OpenVPN, POP3S, SMTPS, etc, even for individual SMIME accounts.

Having a single root CA for your organisation is a lot better than being held to ransom by the recognised CAs who'll charge you for each and every server you want a certificate for, and dare to charge you a "license fee" if you want to put the same cert on multiple servers in a load-balanced cluster.

share|improve this answer

try CAcert. they are free, you just need to have the root installed. one step above having self signed certificates.

share|improve this answer
I have used CAcert, but had hoped they would make better progress toward passing the required audits to become included in major browsers as a Trusted Root CA. I became CAcert Notary and a Thawte Web of Trust Notary and encouraged the use of Thawte Freemail certificates for S/MIME e-mail signing and encryption; unfortunately, Thawte discontinued their program in November 2009 after years of neglect. StartCom has a similar WoT model to add a bit of validation to their free certificates, but there are few notaries around to date; an expansion of their WoT would fill the void left by Thawte... – jnaab Jun 3 '10 at 18:44

If cost is an issue and you're Windows centric, as Mr. Denny suggests, go with Microsoft Certificate Services and deploy the certificates as part of the Default Domain GPO. You'll likely need three systems, but then can be VMs. You'll need the root CA, which should only be used for issuing the certificates for the intermediate CAs. You should have one intermediate CA as the Enterprise CA and then the third as a "stand-alone" CA so you can issue certs to non-domain assets.

If you've got a lot of clients and you are big enough, you may look at having a root from one of the third party solutions and issuing your own certificates from a CA that gets its certificate from said third party. That way you don't have to deploy the CA's certificate. For instance, there is a solution from GeoTrust.

share|improve this answer

For the low price of starter certs, like rapidssl, I would probably purchase one of these, at least if you only need a minimal amount of them. I feel its worth the small fee to stop users being asked to accept the untrusted self signed cert, as it always causes some issues with non-technical users.

share|improve this answer

Assuming that you are a Windows Domain for your desktops, setup a Windows CA in house which will automatically be trusted by all the computers in the company via AD. This way you can issue certs to what ever internal apps you need without having to purchase a cert.

share|improve this answer

Usually, yes, I'd use a self signed PEM certificate for such things. However, how sensitive is the site on your intranet? There are good practices to follow regarding the machine that actually signs the certs .. and others, which may or may not apply to you.

Also, how would an internal CA store be configured for users? Once you accept a cert, you'll know if it changes .. which brings me back to good practices involving the machine that actually signs them (i.e. sign, then unplug it).

Its handy to have your own internal CA, if you manage it correctly. Please provide more information.

share|improve this answer

The problem with a self-signed cert is the clients will generally spew warnings about it being unverified. Depending on security settings, some may block it altogether.

If this is purely an internal need, why even use https instaed of http?

Personally I'd either stick with http or buy a cheap cert (they're not that expensive).

share|improve this answer
Well, there is internal, and internal internal. I.e, you would want https when core developers pushed changes to some repository so that a geek working in human resources (that isn't yet known to be disgruntled) can't cause issues later. An internal CA can be really handy. – Tim Post May 2 '09 at 19:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.