Why is using a certificate, made with the MakeCert tool, in production bad?

Question

I'm currently working on a project where I've created a CA cert and a couple of child certs to that CA cert. The certificates are going to be used to protect inter-server communication in a SAMLV2 setup so I'm going to have a cert for the identity provider and a cert for the service provider. The user/browser isn't going to validate the certs so it's only the servers that need to trust my custom CA. My cert tree looks something like this:

• CustomRootCACert
  • CustomIdentityProviderCert
  • CustomServiceProviderCert

Now, I've heard a lot of people saying it's bad to use a home-made certificate in production. But when I ask why, people usually just mutters something about security but never go into the details. Are there any technical reasons not to use my own certs in production? I can't think of any... Of course I realize that if I lose control of my root cert anyone could start creating all sorts of certificates. But in this case they would also have to install the certificates on my servers and configure the saml application to use them. Only then could they start to generate fake saml requests and responses to my applications.

If this is the only problem, this solution (using home-made certs in production) would still be better than the login setup we have today.

Plow

Answer 1

Ask yourself what a certificate proves.

If you get a certificate issued by a reputable CA, then it proves that the certificate holder has verified their identity to that CA, to their standards of proof.

If you get a certificate issued by an ad-hoc CA, then it proves that someone knows how to make certificates.

If you control both ends of the conversation, I think it's fine to have your own private CA for the purpose. You would trust your own CA. You can probably make this very secure indeed (by keeping the CA private key in a safe place offline, and making signing a sneakernet exercise).

The difficulty would be if you needed to persuade anyone else to trust your CA. Why should they? You would need to convince them that it was safe to do so, and they would have the admin overhead of adding your CA certificate to their clients.

Bowie

Answer 2

Since you are only using the certificate to protect the network traffic and not authenticate users/computers then it sounds like you have a legitimate use for using MakeCert.exe.

I feel there is one thing worth mentioning. After you spend some time working with the MakeCert.exe interface you might to consider using a Stand-Alone Root Certificate Server instead.

Consider these points:

• (Almost) All versions of Windows Server include Certificate Server Services for free
• Windows Stand-Alone CA Server is extremely simple to install and configure
• Windows Stand-Alone CA Server can be installed on a Virtual Machine and turned on/off whenever you need to issue an additional certificate
• A VM based Windows Stand-Alone CA Server can be run using very little memory (ex. 256mb)
• Windows Stand-Alone CA Server includes a nice and clean web based enrollment interface to simplify requesting certificates.
• CRL checking can be used or not used, depending on your needs.

In the past I first started with selfssl.exe and eventually moved to MakeCert.exe to generate a root certificate and then issued my client certificates. But after struggling with the syntax and always having to remember where I put that Root Certificate I switched over to using a Stand-Alone Root CA in a virtual machine.

Braddock

Answer 3

IF the certificates are only passed around internally, between your own servers (and not used by the client, one way or the other) - then it is perfectly acceptable to use your own internal CA.
HOWEVER, one suggestion - dont have your Root CA issue your provider certs. Instead, use your Root CA to create an Intermediate CA - then use that to issue provider certificates. This will help you longer term, when you have to start managing certificate expiration, extending the system/infrastructure, revocation lists, etc.

Fluorocarbon

Thanks for the advice! Do you have any links to further info on this practice? – Plow

try this: technet.microsoft.com/en-us/library/dd277378.aspx#EGAA. At least to start with... – Fluorocarbon

Wow that's huge... Thanks! :) – Plow

Revocation doesn't really matter since the self signed cert doesn't contain a certificate revocation list endpoint. Also, chances are they used a very long expiration date since there isn't any autoenrollment for self signed certificates. – Braddock

He's talking about using an internal, self-owned CA - thats not the same thing as a self-signed cert (where the cert signs itself, no CA whatsoever). In this case, there IS a CRL, and the long expiration dates are also subject to their own issues - which was kinda my point exactly... – Fluorocarbon

Answer 4

There is no real issue with using a self signed certificate in private use, that is use when you control all of the systems that need to trust the homebrew root certificate.

You manually install your root cert onto each of the systems that need to trust it.

You can do this in production as well for browser use - for example within an organisation where the root ca can be rolled out via software distrubution method - there is no reason to go to the expense of paying a Certificate Authority that Microsoft happens to trust.

[edit] In terms of secruity the issue is one of containing the private key for your root certificate, as long as you can ensure that stays private then you can validate any certificate off that root.

Isidora