S 2.232 Planning the Windows CA structure in Windows 2000 and higher

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Head of IT, Administrator

Starting with Windows 2000, Windows comes with its own PKI components to enable establishment of a company-wide certificate hierarchy. Certificates are used to confirm identities of people and systems in cryptographic processes such as encryption, for ("certificate-based") authentication or for electronic signatures for data and applications. The heart of a public key infrastructure (PKI) is the certificate authority (CA), which is authorised to issue certificates. It is generally not necessary to operate a CA in order to operate Windows, but operation of a CA is necessary if you want to use certain properties or functions. This includes smart card logins or secure communication between Windows system components using SSL. Windows offers two types of CA:

The main difference between the two types of CAs is that the enterprise CA is integrated into the Active Directory and can therefore benefit from the use of the Active Directory as a directory service. For example, certification authorities can be made public in the Active Directory, and then large numbers of certificates can be issued and distributed automatically. With the stand-alone CA, the certificate request is always checked by the CA administrator, and the generation of a certificate must be triggered manually by the administrator. The creation of certificates must be triggered manually by the administrator. The stand-alone CA can also be installed and operated on a non-networked computer, whereas it only makes sense to run the enterprise CA on a networked computer. In Windows Server 2003 Enterprise Edition and higher, the certificate templates for the enterprise CA can be customised individually.

Both CA versions are suitable for establishing a certificate hierarchy, and therefore both versions can also be operated as secondary CAs. The enterprise CA is better suited for use in a LAN infrastructure, and this version should normally be preferred. In hierarchies with several levels it is recommended to operate the highest hierarchy (root CA) offline since its key as a "trust anchor" of the overall hierarchy is particularly worthy of protection and the CA is seldom required for issuing the certificates for the sub-CAs.

It must be ensured that all operational scenarios and the applications affected by the scenarios are known, especially when planning a government-wide or company-wide PKI. To estimate the technical feasibility, it is recommended to check the interoperability of all components to be used in advance.

A list of structural planning aspects can be found on the BSI website under the Resources for IT-Grundschutz (see Resources for planning the Windows 2000/2003 CA structure). It is generally true that all general organisational, technical, and security-related conditions relevant to the operation of a CA must be documented in a corresponding concept.

Planning the use of suitable certification authorities

Organisational aspects:

Technical aspects:

The security during actual operation of the individual PKI components plays a particularly important role, as well as the planning of a PKI. A certificate authority must be protected according to the protection requirement of the particular applications in which the certificates are used. Recommendations for protection can be found in the Resources for IT-Grundschutz (see Resources for protecting certificate services under Windows Server 2003).

Version-specific planning aspects for a CA in Windows Server 2003 and higher

Distribution of certificates:

Certificates can be requested and issued (short: distributed) automatically (without user interaction) or manually. The automatic distribution of certificates (autoenrolment) is based on Active Directory and group policies (see also ). Autoenrolment simplifies the administration of certificates of users (under Windows Server 2003 Enterprise Edition and higher) and computers for specific applications in the organisational environment. A common example of this is the distribution of encryption certificates for the Encrypting File System (EFS) among the clients. The certificate enrolment procedure is only performed for authenticated clients and is equipped with corresponding security mechanisms and authorisations. The settings are found in the Group Policy Object Editor under

Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Properties of the Autoenrolment Settings

and

User Configuration | Windows Settings | Security Settings | Public Key Policies | Properties of the Autoenrolment Settings.

By default, only domain controllers automatically request a computer certificate. Furthermore, some optional Windows components also automatically request a certificate. In this way, every client with activated EFS automatically receives an EFS certificate. The scope of autoenrolment used should match the scope actually needed because otherwise administration becomes more difficult and there is a risk of the keys being disclosed, among other risks.

Based on the applications or Windows components you plan to use, you must consider which certificate types will be permitted to be used by which users and computers, and how the certificates will be distributed. The group policies and authorisations in the certificate services must be planned accordingly.

Archiving private keys:

The archiving of private keys in the certification authority (available in Windows Server 2003 Enterprise Edition and higher) is not recommended. It should only be activated when a suitable role separation concept for PKI administration has been planned and implemented. Archiving can reduce the risk of an individual user losing his keys, but comes in combination with a higher risk of misuse of the archives. The suitable strategy depends on the applications and components used and should be specified by the PKI planners and documented in a security policy.

Separation of roles:

Separating roles means preventing the concentration of several or all critical administration roles arising in conjunction with the PKI in a single person or a single user account. To separate the roles, each role must be defined first at the organisational level, as described above. The separation of the roles can be enforced technically by the system (in Windows Server 2003 Enterprise Edition and higher). The four roles are:

Detailed information on the roles can be found under the subject of role-based administration in the integrated Windows help system.

A user account that previously assumed two or more of the roles mentioned above must be excluded from all administration activities on the CA through role separation. The roles must be redistributed in this case by an administrator. If the role separation configuration is incorrect, then the CA is unusable. If you want to implement role separation, then you must first create a suitable authorisation concept, which should then be tried out in a test scenario.

Review questions:

© Federal Office for Information Security. All rights reserved.