Is it possible to create a self signed certificate authority?

Question

Would it be possible to create a legitimate certificate with the CA bit set? I dont have a usecase associated with this, I'm merely curious.

To explain my question : Suppose I sign a public key(belongs to "B" whom I trust), would it be possible to let "B" alone sign other public keys(beloning to "C", "D", "E" etc) such that I would be the known trusted root? "C", "D", "E" etc should not be allowed to sign other certificates that have me as the trusted root.

My understanding is that when I sign the public key, the CA bit would have to be set -- however when "B" signs it, the CA bit would be unset.

Is that so?

Answer 1

What you describe is a "Private CA certificate", and they are used everyday. A "self-signed certificate" is any certificate that does not have the digital signature of a higher certificate authority; the certificate basically tells someone who gets it "I am vouching for myself; you can either trust me or not". SSCs can assert that they are CAs, and so if you trust them, you trust the certificates signed with the CA certificate. The self-signed CA certificate in effect becomes a "private trusted root". Because it lacks global trust, this certificate generally isn't good enough for an anonymous client connecting to your web server over the Internet, but within the boundaries of a network of computers that you fully control, you can tell those computers to trust any certificate you like.

Without a central authority, every machine on the network would require the certificate of every other machine on the network, and implicitly trust all of them. This simple flat "web" trust structure is feasible for a small number of machines like 3-5, but in a network with, say, 100 machines, each machine must have the certificate for the other 99, and the next machine to be added to the network must somehow get its certificate implicitly accepted by all 100 existing machines. The CA structure drastically streamlines this process; all machines implicitly trust one and only one certificate - the CA's - and a CA-signed certificate presented by a new machine will tell all the other computers "the CA trusts me; you should too".

Now, this still requires your CA to be trustworthy; just because it's trusted doesn't necessarily mean it should be. The CA certificate's private key has to be protected against attempts by an attacker to steal it, and should an attacker do so, you must have a way to revoke that certificate without losing all trust in the entire network. In a small home network, as AJ's comment states, it's not a huge deal to revoke the one primary CA certificate and regenerate all the certificates on the network, but in larger networks it can bring the whole thing to a screeching halt.

Typically, redundancy and tolerance to compromise is achieved with multiple levels (at least two) of CAs in your trust chain, much like the globally-trusted CA chain works. There would be one "trusted root" certificate, a "golden key", the public version of which is implicitly trusted by the network machines. The private key is stored on an HSM, and when not generating "public-facing" CA certificates it is kept in a secured vault that requires sign-off from multiple executives to access.

Those "public-facing" CA certificates are the ones used by the PKI server(s) to generate the non-CA certificates issued to servers and clients on the network. Should an attacker compromise one of these CA certificates, that certificate can be revoked (telling all computers not to trust it or any certificate signed by it), and any computer that had a certificate signed by that CA can prove its identity in some other way to the PKI system, and get a new certificate from one of the non-compromised CA certs. Meanwhile, the execs sign off, the HSM is retrieved under the watchful eye of a lot of interested people, and a replacement CA certificate is generated to replace the revoked one in the PKI system.

Answer 2

Yes, that is possible. This is just certificate chaining. You can make a certificate with any settings you'd like to, the only problem is that unless someone's computer has specifically trusted your root certificate it won't trust any of the certificates that derive their trust from your root.

This is generally called a private CA or enterprise CA and is used very regularly for enterprise PKI. The exact details of how to set one up are probably beyond the scope of a QA site, but a quick Google search for "private certificate authority" or "enterprise certificate authority" should get you all the details you would need to know about it.

Answer 3

This intention is not well explained. The mentioned scenario is not that clear too. There are some facts. CAs certificates cannot be categorized as self signed certificate issuing points. You use ssc when there is no CA to carry out the task. I assume you are assuming that after a CA issued a certificate to a user, that users given the ability to create a ssc. Or create a certificate on behalf of the main issuing point. The second method can be achieved but there are certain requirements. As an example, with Windows servers and a pki, if a certain user or a computer is trusted by a domain controller, it is possible to issue certificate on behalf of users etc. Also applicable when smart cards deployment is required. It is also possible to enroll non-domain members as well but the requirement is to have a valid profile with a client which has the root cert installed. You can have more than one enrollment agent and issuing points distributed. This is also true with commercial certificate authorities. They delegate trusts. Distribute issuing points under various policies. But note that there are requirement profiles for each scenario. And a way of trust. It is possible to establish chains of trust with CAs but not with SSCs.

Answer 4

I had to add another answer due to the reason that the question either changed (edited) or misunderstandings happened and have to apologize. The original question had the word Self Signed Certificate which made confusions. If you are using a CA there is no need to create self signed certificates. What you are mentioning here is a private CA hierarchy. SSC does not require CAs. But CAs have self signed certificate (i.e. Trusted Root). Issuing CA hierarchy sign certificates by the hierarchy itself. SSCs are just signed by a certain person or a server. If you wish to use chaining it does not matter whether it is internal or external (private or public). It is quite possible to create the chain of trust with a PKI. That is the main intention and what you are actually mentioning.

When considering the internal network it is possible to create a hierarchy of 2 or 3 layers of certificate service levels for better security. Top level or root CAs can be used only when it is necessary and usually kept offline while issuing CAs do the job (level 3). It is used to issue certificates for the hierarchy and not end users/devices. Intermediate CAs can be used to issue certificates for Issuing CAs. There could be policy servers as well, a special server to govern the policies for each level. Issuing CAs issue the certificates to users, computers, devices etc. In order to check whether the certificate is revoked, it is possible to use certificate revocation lists and for external access it is possible to deploy OCSP servers. The intention of the certificate evocation is to prevent certificate compromization and trust issues. If the certificate requires not to be trusted or it is no longer needed, it can be revoked or suspended until the issue gets resolved.

By this way it is possible to acquire a chain of trust and status. But note that certificate revocation has vulnerabilities. This is why Google dropped the CR. Chain of trust and trust propagation is the intention of a well established CA Hierarchy.

For the enterprise you do not need a complete hierarchy. Even an Enterprise root ca can be deployed. However, still the gaps have to be maintained. It is highly encouraged the administrators to deploy subordinate certificate authorities and a separate policy server. But this is not very economical when it comes to small networks. But still it provides better security. You could even use smart cards with a proper PKI. However, note that there is a challenge with external access to CRLs with an enterprise private PKI. But still its efficient if well planned.