česky | english
Contents were taken from SubRoot page
- Intermediate Certificates and Sub-Roots are treated the same in this page.
- the only ones talked about here are the ones issues for or on behalf of another organisation, acting as a sub-CA.
- Elsewhere, we talk about our own Sub-Roots for Class 1, 3, etc.
Intro to Organisation Sub-Root Certificates
Question: I would like CAcert to sign my Sub-Root certificate so I can sign other certificates. Is this possible?
Answer: The short answer is no.
Because we are seeking inclusions in mainstream browsers we have been advised that this would not only complicate things, it might also potentially exclude us from ever being included.
This is because there are difficult questions. For example, whether we have control over who the 3rd party organisation is issuing certificates to, ensuring that organisation is sticking to the practices and policies, who has access to the private key, and so on and so forth.
At this point in time Sub-Roots are not planned, but are being researched for the future. Right now, it isn't something we are willing to risk after all the hard work people have put into working towards the goal of browser inclusion.
Answer: The longer answer is Maybe. This page discusses potential future ways to achieve this.
Automatic certificate issuing
If you are interested in automatic issueing of certificates, we already have the following options for you:
Certificator is a tool to automatically generate certificates for a large number of users, with e.g. LDAP
AEP is the Auto-Enrollment Proxy to automatically issue CAcert Organisation Certificates for Active-Directory
With the CertApi you can integrate automatic certificate issuing in any other application (which is also used by Certificator)
Note: these will need to be tied into the OAP and CPS.
Managed Intermediate Certificates
The so-called "Managed-Pki" solution is a system whereby a CA would issue an intermediate certificate to an organisation. This would enable the organisation to limit reliance-applications to the certificates that are issued by that intermediate certificate. what does that mean???
Under this proposal, CAcert would create a dedicated Intermediate certificate, and operate that intermediate certificate for the organisation. In order to issue end-entity certificates, the Intermediate certificate could be managed via the normal webinterface, and/or the CertApi. CAcert would provide a stable, automatic interface to issue certificates for the Intermediate CA.
As the CA operates the Intermediate CA, it also enforces the policy. It is an open question as to whether this would be the same policy as CAcert in general or whether there are variations possible.
In principle, this might mean that the Sub-CA would not be separately audited.
If an organisation has high-availability demands for certificate issuing, or any other reasons that makes it necessary that you operate your own CA in-house, then there are 2 possible avenues:
RFC 3280 defines a DNS Name Constraint extension into X.509 certificates, so that Sub-CA´s are limited to a specific domain + subdomains. CAcert might support this in the future.
MicroCA: Since not all software systems support RFC3280 yet, we are thinking about how to create a MicroCA implementation in a SmartCard or an HSM, which will enforce the name constraints inside the secure hardware, to make sure that it works with all existing software.
For unconstrained Sub-CA´s, CAcert will likely impose the same requirements it faces, including own policies and the Mozilla policies.
The cost of this programme might run to a few hundred thousand EUR/USD, and thus it will likely be more economic for the end-company to to get included into the browsers directly as a whole CA, instead of getting a unconstrained Sub-CA from CAcert.
Any Other Options?
If you have any specific needs that cannot be handled with the existing programs already available, please contact us.