There are many Digi-CA™ advantages [1] when compared to Microsoft® CA. This is particularly important when considering estimated Certificate requirements in terms of millions of users, where the certificate life cycle and archival are critical. If this is your requirement, or is ever likely to become your requirement during the life of the CA, then Microsoft® CA is simply the wrong choice for you.
As a commercial Certificate Authority [CA] system, Digi-CA™ can support large volumes of Certificates and with the correct choice in hardware, should be a key consideration in the success of a large environment. The design of the Digi-CA™ system is such that it is capable of 'starting small' and 'growing as you grow'. This is possible by simply adding more hardware and this can be added to the live system, without interrupting its operation. This design feature it makes the Digi-CA™ PKI system suitable for almost any kind of environment.
Digi-CA™ does not support the Microsoft® AutoEnrolment for users and computers. This is an important feature that is used regularly within 'Microsoft® Environments' and 'Microsoft® Houses' and is very useful for automatically renewing users system access rights. However, this is only important when considering a 'closed group [2]'.
The Microsoft® CA 2003 provides support for cross certification of the CA it operates. If its internal Root CA is cross certified against an external Root CA, from Digi-CA™ for example, this is fully sufficient for the entire PKI infrastructure to inherit trust throughout the entire certification path and thus any subordinate CA in the chain will automatically inherit trust from its superior authority up to the internal Root CA.
Therefore, with the internal Root CA cross signed, the level of trust will be automatically extend throughout the entire chain and the internal Root CA will become the subordinate CA in the certification path, whereby the trust is inherited from the external trusted Root CA, from Digi-CA™.
If you currently have a Microsoft® CA solution that operates a Subordinate CA that chains up to the Root CA operated on another CA system, like RSA® Keon® for example, then this can easily be replaced by Digi-CA™ without interrupting the continued support of the existing CA hierarchy as it is operated at the moment.
We recommended that the approach would include getting this cross certified Root CA against an external globally recognised and trusted Root CA.
1. Microsoft CA does not offer the ability to design a custom CA hierarchy as a basic component of the system. It also does not offer the ability to operate multiple CAs from a single system instance. In a PKI environment, where different CAs may be required for different purposes (such as in case of National CAs) and a custom design for a CA hierarchy with multiple Subordinate CAs is required, Microsoft CA will not be able to operate such an environment.
2. Microsoft CA does not provide a centralised and web based system management centre. Although this feature may not be a mandatory requirement for operating a typical CA system, it is a great advantage which gives users the ability to manage the CA from non-Windows based computers. Management of Microsoft CA is possible only from a Windows based computer.
3. Microsoft CA uses its own database engine to store digital certificates, certificate requests and Certificate Revocation Lists and does not provide any features for detailed reporting on its PKI related data, such as advanced search options on issued, revoked, expired and pending expiration certificates, which are key to a successful and easy managegement of a PKI infrastructure.
4. Microsoft CA does not provide multilingual features, whereby the native language of the CA software is the one, in which the software was supplied with. The market presents a large need for a feature whereby users and administrators could set the desired language within a click of a button, which is not provided in Microsoft CA.
5. Microsoft CA does not offer the customisation of the number and type of enrolment fields on the application form, at will. Customisation of the help files and their localisation is not straightforward and batched certificate delivery is also not supported at all.
6. Microsoft CA also lacks a feature for generating detailed log of events such as certificate requests, signing operations which is a key component to operate a professional CA system. It only provides a basic level of logging.
7. Microsoft CA does not support certificate delivery in PKCS#12 format, which may be a requirement for some organisations.
8. Microsoft CA does not provide the ability to register new custom X.509 extension fields or X.509 Distinguished Name attributes. There are instances where organisations may require some custom X.509 DN attributes for specific workflow processing and with Microsoft CA, that is not possible.
9. Microsoft CA does not provide extended alerting system which makes an administrator or a user aware of a specific event, such as new certificate request, certificate revocation, certificate delivery, certificate expiration and so on. For an open environment, such as in case of a National CAs, notification mechanisms are a key to a success of daily CA operations and harmless troubleshooting and end user support.
10. In many instances, organisations may wish to customize the look & feel configuration of the management and end user interfaces of their CA system and this is a key feature to a business success, which is not supported by Microsoft CA.
11. In Microsoft CA, only domain-joined machines can use ‘Certificate Autoenrollment’, which makes this function is useless in a wide scale certificate deployment (outside organisation private network).
Links:
[1] https://www.digi-sign.com/certificate+authority/traditional+ca
[2] https://www.digi-sign.com/digi-ca/administrator/certificate+authority+selection