Traditional CAs

Understanding the Traditional CA 'Handicaps'

Certificate Authority [CA] software and solutions that have 'grown' over time from the late 1990's and early 2000's can be grouped together and referred too as Traditional CAs. These CAs are unlike the Modern CA [1] systems and the following observations are general to most of these CAs. Then there are further observations, specific to Microsoft® CA [MS-CA]. These are set out in the following sub sections.

Important Observations on the Traditional CA

There are three primary differences between the Traditional/MS-CA and more modern CA systems, namely:

• a) At a high level, many traditional CAs do not offer the ability to design a custom CA hierarchy as a basic component of the system (this can be offered on request but at increased cost and significant implementation time). Nor do they offer the ability to operate multiple CAs from a single system and many CA systems lack a centralised web based system management centre.




• b) Many traditional CA systems keep issued certificates, certificate requests and CRLs in different flat database files that make system customisations to support third party systems almost impossible. This means that detailed reporting along with search options on issued, revoked, expired and pending expiry certificates is not possible. Also, as these databases are flat file they are not UTF-8 compliant and can present significant difficulties when localising the system into your language.




• c) Traditional CAs do not offer the customisation of the number/type of enrolment fields on the application form(s), at will. Customisation of the help files and their localisation is not straightforward and certificate delivery using a .csv file may also not be supported at all. There are also other deficiencies relating to web based enrolment being limited to Microsoft® Internet Explored browsers and API development for third party integration being either severely hampered (and therefore slow and expensive to produce) or too restrictive to be considered practical.

The following list summarises the deficiencies in most traditional CA systems:

• Inability to design a custom CA hierarchy




• Inability to operate multiple Certification Authorities




• Centralized web based system management centre not present




• Access to the system management is not two-factor, (USB key or smart card)




• Issued certificates, certificate requests and CRLs are kept in different flat database files, which makes proper reporting, querying and single user management (or even system customizations to support third party systems) almost impossible




• Track/log of users and administrators actions not possible




• .p12/.pfx Certificate file delivery not supported




• Full customisation of the x.509 extension fields for issued certificates not possible




• Detailed reporting along with search options on issued, revoked, pending for expiry and expired certificates is not possible




• Expiry reminder email notifications & customization not present or not possible




• Customisation of the look and feel of the management centre interface not possible




• Localization of the management centre is not possible




• Customisation of the look and feel of the user enrolment application not possible




• Localization of the user enrolment application is not possible




• Customisation of the number and type of enrolment fields on the enrolment application form not possible




• Customizable of the help files is not possible




• Localization of the help files is not possible




• Certificate automated delivery using a .csv file not supported




• Web based enrolment is practically limited to MS IE browsers only




• API development for third party integration is severely hampered and therefore slow and expensive to produce

Specific Observations on Microsoft CA

Specifically, in the case of Microsoft® CA [2] (and also Lotus Notes in certain instances) the following specific deficiencies can be found:

• Windows Server 2003 schema and Group Policy updates, which limits the operating system platform vendor and version




• Windows 2000 or Windows Server 2003 domain controllers with Active Directory properly configured for MS CA services, which limits the network infrastructure type where the CA operates




• Windows XP Client, which limits the client operating system platform & version




• Windows Server 2003, Enterprise Edition running as an Enterprise CA limits the operating system platform that the CA can be operational on & integrated with




• Only domain-joined machines can use ‘Certificate Autoenrollment’, which makes this function is useless in a wide scale certificate deployment (outside organisation private network)




• 'Certificate Autoenrollment’ service does not work when a certification authority (CA) certificate is renewed, which is a bug in Microsoft software preventing the solution to operate uninterrupted after the CA certificate renewal.




• As an example, how and who will build the API to link to the HZZO database so that you can issue the Microsoft® Certificates and what experience of doing this does the vendor or provider have in this area?

Read More [2] about the Microsoft® CA