Re: Self-Signed certificates issued by an Internal CA

[Valdis Kletnieks <Valdis.Kletnieks () VT EDU>]

On Wed, 16 Dec 2009 16:28:00 CST, Tarun Trivedi said:

> I would like to learn if there are best practices in management of
> internal self-signed certificates that are used to trust institution's
> internal network services.

Umm... *self-signed*, or "signed by your internal CA"?  There's a *huge*
difference between the two - in particular, the latter can be made to
be totally equivalent to a "regularly signed" certificate by simply installing
the appropriate CA certs that did the signing.  After that, the question
becomes "How much do you trust the policies of your internal CA, and the
staff ability to follow them?"

A true self-signed certificate is a different kettle of fish - it can be
used to verify with a very high degree of reliability that you're connecting
to the same instance of something as you did last time (modulo compromise of
the associated private key, but you have that same issue with a properly
signed cert, so it's a wash).  However, you don't have any real way to
identify what the "something" is, since it's not signed by anybody else.

> Specifically, if there is a standard in setting up expiration date or
> if there are any risks in setting up maximum allowable time limit. If
> there is a central way to monitor certificates issued by various OS's
> and applications.

In general, you shouldn't be seeing many certs issued by an OS or application
that have your CA in the signer chain (unless you have delegated cert-signing
authority to an app for some business reason).  Many OS's *do* have a
habit of popping out a self-signed cert anytime they need to start OpenSSL
for a service and can't find a sysadmin-installed cert.

Yet another reason to be clear regarding self-signed versus private-CA-signed.

Attachment: _bin
Description: