1

I hope this is the right stackexchange - if not, please advise.

As to the actual question: have a system we've developed that makes heavy use of asymmetric cryptography in various different ways (RSA, client certificate authentication, and digital signatures), and in our recommended configuration uses 8 certificates - 4 SSL certificates, 1 signing certificate (for SAML), two client authentication certificates, and an RSA certificate (for protecting symmetric keys.) In our development and test environment, we've used self-signed certs generated with the makecert.exe utility, but that's not at all suitable for production.

What we'd like to know is: can you acquire and/or buy those sorts of certificates from a certificate authority? Will any old certificate do? So far, we've only found SSL certificates for sale and talking to support at various vendors has been..less than helpful.

We're also considering setting up a CA on site (with Active Directory Certificate Service) to cut down on the number of certificates that have to be purchased, which leads into the same vein: can you purchase/obtain a certificate suitable for use as the root for a local CA from an upstream CA? Is it basically an SSL certificate?

Improve this question
1
  • You can have your own CA, but you'd have to trust its root certificate in any client that's exposed to the certs signed by it. For internal apps, this is very easy with group policy.
    – Nathan C
    Apr 9, 2014 at 19:36

2 Answers 2

Reset to default
2

A certificate is basically a binding between an identity and a public key, but there are details:

  • The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...).
  • The lifecycle of the private key matters: who generates it, where it is stored, whether there are backups...
  • The certificate contents may activate or deactivate some usages, and you may want some control over that.

If you want to produce your own certificate, then you want to operate your own Certification Authority. There is nice opensource software for that (e.g. EJBCA). However, this course of action entails two main cost areas:

  1. You have to operate the CA. PKI is 5% technology, 95% procedures; having the software is fine, but running it, managing physical access, renewals, audit... will be what costs the most, by far.

  2. Certificates from your CA will be accepted by your machines only if the public key of your CA is installed in these machines as a root CA, or if your CA has been issued by another CA which is installed in your machines as a root.

Using certificates from a "commercial CA" solves the second point, but at a heavy cost. In particular, if you want to have your own CA, then it must be marked as a "CA certificate" (that's written in the Basic Constraints certificate extension). A commercial CA may accept to issue to you a CA certificate, signed by their own, but it will be expensive (think thousands of dollars, at least); and they will require that you operate your own CA within strict rules (including insurance, publication of a detailed and legally binding Certification Practice Statement, and so on).

If you just want to produce certificates for your own usages, on systems that you control, then it makes relatively little sense to rely on a commercial CA: it is much easier to simply have your own root, and install it in all relevant machines.

It is also quite possible that your problem at hand does not actually call for true "certificates". Certificates are a solution to a key distribution problem: the point of certificates is that a given system can gain knowledge a public key, and confidence in the identity of the key owner, dynamically, by virtue of seeing and validating a certificate. If, in your system, there are 8 keys altogether and you have control over all client and server, then chances are that you do not really need certificates; you just want asymmetric key pairs. Public keys are published a priori (pushed through configuration or hardcoded in relevant software).

For easy and cheap compatibility with existing protocols (e.g. SSL), it may be convenient to encode the public keys as something which looks like "certificates"; traditionally, these certificates will be "self-signed" because there is a non-optional field for a signature in the certificate format.

There is nothing intrinsically wrong with self-signed certificates if they map to your problem at hand. There is no need to invoke a PKI if your situation does not have a key distribution issue.

Improve this answer
0

To keep it short and simple.

Is there a need for external trust? If what you wish to protect is for internal use only, there is no need for an external CA like GoDaddy or Symantec.

With a deployment service you can provision the affected nodes with the CA cert used to create trust in the 'network'

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .