[[SubRoot/CZ|česky]] | '''english''' ''Please refer to [[Roots/OrganisationSubRoots]] page for more.'' = Sub-Root certificates = Question: ''I would like CAcert to sign my 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 but potentially exclude us from ever being included. This is because we have no control over who you are issuing certificates for, ensuring that you are sticking to your practices/policies, who has access to the private key, so on and so forth. At this point in time it isn't something we are willing to risk after all the hard work people have put into working towards this goal. '''Answer: The longer answer is yes.''' == Organisations == If you are looking for an easier way to manage certificates within a legally recognised organisation you should take a look at our OrganisationAssurance system: OrganisationEntities. == Automatic certificate issueing == If you are interested in automatic issueing of certificates, we already have the following options for you: * [[Certificator|Certificator]] is a tool to automatically generate certificates for a large number of users, with e.g. LDAP * [[AEP|AEP]] is the Auto-Enrollment Proxy to automatically issue CAcert Organisation Certificates for Active-Directory * With the CertApi you can integrate automatic certificiate issueing in any other application (which is also used by Certificator) == Intermediate certificates == If you really need an intermediate certificate (so that you can limit reliance-applications to the certificates that are issued by that intermediate certificate), then CAcert could offer a so called "ManagedPki" solution, where CAcert creates a dedicated Intermediate certificate, and operates that intermediate certificate for you. You will be able to use both the normal webinterface, and also the CertApi to issue certificates that way. With this scenario, CAcert operates the Intermediate CA for you, and enforces the policy of the Sub CA for you, so that you don´t need to get your own Sub-CA audited. CAcert will provide you with a stable, automatic interface to issue certificates for your Intermediate-CA. == Constrained Sub-CA´s == If you have high-availability demands for certificate issueing, or any other reasons that makes it necessary that you operate your own CA in-house, then we could offer 2 possible ways to achieve that: * RFC 3280 defines a [[DnsNameConstraint|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|MicroCA]]: Since not all software systems support RFC3280 yet, we are planning to create a [[MicroCA|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. == Unconstrained Sub-CA == For unconstrained Sub-CA´s, CAcert will likely have similar requirements to these: http://www.mozilla.org/projects/security/certs/policy/ I guess that you should allocate a few hundred thousand EUR/USD for the costs of that program. And in the end, it will likely be easier to get included into the browsers yourself, instead of getting a unconstrained Sub-CA from CAcert. If you have any specific needs that can´t be handled with the existing programs already available, please [[GettingSupport|contact us]]. ----- Back to [[FAQ/TechnicalQuestions]]