February 26, 2018 at 11:47Installation of a certification authority in an enterprise. Part 2
- Tutorial
We continue our series of articles on the enterprise certification authority. Today we’ll talk about building a public key diagram, planning the names of a certification authority, planning certificate revocation lists, and a few more points. Join now!
The following abbreviations and abbreviations are used in this part of the series:
Successful implementation of any technical solution requires careful planning. PKI implementation is no exception. Moreover, if in certain cases the errors of the initial planning can be fixed relatively quickly and easily, then in PKI this is definitely not the case. As I already noted, PKI services are designed to work for many years with minimal (or non-critical) changes in the course of work.
For example, the validity of CA certificates is about 10-20 years. One of the reasons for such a long lifespan is that re-issuing these certificates is a somewhat time-consuming operation and may require changes to a large number of customers. This is compounded by the fact that changes will be required on clients that you may not have access to. Another point is that when you make some changes to the PKI architecture, you will need to maintain the current configuration for the lifetime of the issued certificates. In other words, a new configuration will work for new certificates, but in parallel with it, it will be necessary to maintain the previous configuration so that already issued certificates can work correctly. This also adds to the difficulty of maintaining PKI in a healthy state.
Given these points, PKI planning should be approached in the most serious way. And only then PKI will successfully fulfill its functions in ensuring digital security for a long time.
The multi-stage planning process is based on the logical diagram of the selected model. At each stage, the elements of the diagram are expanded (detailed) and for it the connections, tasks and requirements are formalized. If necessary, detailing continues until a fully formalized system is obtained. This article demonstrates an example of this planning approach.
As I said, it all starts with a logical diagram of the selected model. The logic diagram displays all the PKI components and it should be shifted to the physical topology. In the case of applying the two-level PKI model, such a diagram can have the following form:
The diagram shows the following components and their logical connections:
The physical topology will be slightly different and have the following form:
The physical topology explicitly emphasizes that the revocation server is available to all clients, both inside and outside the network, so that clients can verify certificates anywhere.
The name of the CA is the name that will be displayed in the
For Standalone CA: <
For Enterprise CA: <
Is this good or bad? Technically, you can choose any name, functionally it will not affect anything. It is believed that the name of your CA is in some way the visiting card of your PKI, reflecting your attitude to details that are not directly related to functionality, but provide a sufficient level of information and openness. Therefore, when choosing the full name of the certificate, you should be guided by several recommendations:
Suppose you select a name for the root CA of the company Contoso Pharmaceuticals Ltd., which is located in Riga, Latvia, and the management is provided by the information technology department. In this case, the name of the CA may be as follows:
Keep in mind that the Country attribute only supports the two-letter country index. For example, LV, GB, RU, US, etc. As additional examples, you can turn to the CA certificates of commercial providers like VeriSign / Symantec, DigiCert, etc. For a subordinate CA, this name will be similar, except that the word Root in the name will be replaced by Subordinate or Issuing. In the case of a three-level hierarchy, where the policy CA is clearly allocated, the word Root will be replaced by Policy. As I noted above, other rules may apply in your company, and you can implement them in the names of the CAs, this will not affect the functionality. In doing so, avoid:
According to the logical diagram, each CA will publish its review list. Our review lists will be characterized by two main categories:
To publish revocation lists, two types of CRL distribution points are used: the publishing point (where the physical file will be written) and the distribution point (receiving) of the file.
The first type of points indicates the local or network path (in UNC format) where the file will be written. The second type of points will be registered in the issued certificates indicating the way in which customers can download the review list. These paths are published in the CRL Distribution Points certificate extension. These paths will generally not match (except for LDAP, where the publishing and distribution paths are the same). In determining the points of publication should be guided by the following rules:
For more information on planning the CRL Distribution Points and Authority Information Access extensions and practices, see my blog post: Designing CRL Distribution Points and Authority Information Access locations .
Before planning the composition and validity of recall lists, it is necessary to understand the purpose of recall lists and the optimal parameters depending on their operating conditions. As you know, each CA periodically publishes review lists, which include lists of all certificates revoked by a particular CA. Moreover, each list includes all revoked certificates for the entire life of the CA. With a CA lifespan of, for example, 10 years, this list can grow to an impressive size (of the order of several megabytes).
Even with high-speed connections, revocation list traffic will be significant in size because all certificate consumers need the latest revision list.
To reduce the traffic of revocation lists, two types of CRLs are to be published: Basic (Base CRL) and differential (Delta CRL). The base list includes a complete review list. The differential list includes only the list of revoked certificates that have been revoked since the last publication of the base CRL. This allows you to publish the basic list less often and for a longer period, and to speed up the response time of clients to the revoked certificates in the interval to issue several short-lived differential CRLs.
The selection of parameters depends on several factors. For example, the planned volume of issued certificates and the planned volume of revocation. Consider typical scenarios.
Root CA
The root CA issues certificates only to intermediate CAs, the number of which is usually within a dozen. The validity period of intermediate CAs is comparable to the lifetime of the root CA certificate. It is also assumed that the risk of recalling subordinate CAs is very low, since they are managed by trained personnel and appropriate security measures are in place. Therefore, it can be argued that the volume of the revocation list can include only a small number of revoked certificates and, accordingly, the CRL file will be guaranteed to be small in size.
Help: how to calculate the planned size of the CRL file based on the size of the review? A typical empty CRL takes approximately 600-800 bytes. Each certificate revocation record is 88 bytes. Based on these values, you can calculate the CRL size depending on the number of revoked certificates.
It follows that throughout the life of the root CA, the recall list will be within 1kb and there is no point in differential CRL.
Publishing CA
For the publisher CA, the picture is changing. The volume of issued certificates is already high, it can be thousands and millions of pieces. Consumers are users and devices that are at high risk of recall because they are not constantly monitored by qualified personnel and it is not possible to provide appropriate measures. As a result, the review list can reach serious sizes. For example, if you put a 10% risk of revocation, then for a million issued certificates there are about 100k revoked. 100k records of 88 bytes will be a little less than 10mb. It is often not very practical to update the file by 10mb, it is more expedient to publish it less often, and to distribute several lightweight differential Delta CRLs in the interval between publications of the main CRL. Those. if for the root CA only the basic revocation list is sufficient, then for the CA,
It was all about the composition of the review lists for each CA. Now you should determine the timing:
Here, you can also apply the approach depending on the operating conditions. The risk of revoking an intermediate CA is very low, therefore, it makes no sense to publish an empty CRL too often. In modern practice, the following typical values for the CRL validity period for CAs are used, which issue certificates only to other CAs: 3, 6, or 12 months. It should be based on the degree of risk and administrative costs of maintaining recall lists. If there are no special conditions, then I recommend choosing something average, about 6 months.
For subordinate CAs, the scheme is the same. Since the risk of revoking client certificates is high, we can assume a high frequency of revocation. Therefore, such a CA should publish review lists much more often, and to save traffic, combine basic and differential CRLs. By default, Microsoft CA publishes revocation lists with the following frequency: basic CRL once a week, deltas daily. In this situation, customers will be notified of the latest revoked certificates within 24 hours.
You can understand the desire of administrators to reduce this time (ideally - instantly) so that customers do not recognize the revoked certificate as valid. However, a decrease in one risk leads to an increase in another risk. Imagine, for some reason, the CA server failed when the previous CRL was close to expiration and the new CRL could not be published. Then the problems will begin with checking certificate revocation and stopping them until the CA server is restored to work. This point must be taken into account when setting the expiration dates for review lists.
Microsoft CA, by default, already lays down some time reserve for unforeseen cases, and when it takes some time to distribute review lists to all publication points (for example, caused by latency of replication). This reserve in English terminology is called CRL overlap. The idea behind the defense mechanism is that the CA generates and publishes review lists before the expiration of the previous published list.
This is achieved by using two fields in the review list: Next CRL Publish and Next Update. The Next CRL Publish field indicates the time when the CA publishes an updated revocation list (automatically). Next Update indicates the time when the current list expires. The Next Update field will always be set a little later than Next CRL Publish. In other words, the CA will publish an updated revocation list before the expiration of the previous one. The algorithm for calculating automatic values for these fields is nontrivial and is described in the following article: How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). If the default values do not suit you for one reason or another, you can edit them. It should be borne in mind that the time margin has lower and upper boundaries. For example, the upper bound cannot exceed the validity period of the CRL itself. So, if the validity period of the CRL is 1 day, then the stock can be a maximum of 1 day, and then the CA will publish review lists daily, but the validity period will be 2 days. Thus, a margin of time is achieved for the restoration of the CA in case of unforeseen circumstances.
In practice, I quite often observed the desire of administrators to twist the CRL expiration settings to the minimum limit with the following rationale: "the user quit and should not be able to authenticate with the revoked certificate." The motivation is understandable, but solving the problem through review lists is not entirely correct. In case the user needs to stop access to corporate systems, it is necessary to disable the user account or computer.
When planning your CRL expiration dates and frequency, you should be guided by the following recommendations:
As part of this article series, I will not use OCSP servers for an additional method of distributing information about revoked certificates. If you wish, you can refer to the comprehensive TechNet article: Online Responder Installation, Configuration, and Troubleshooting Guide . As practice shows, in most cases, the installation and support of OCSP is not justified for several reasons.
The main goal of OCSP is to offload CRL download traffic. As you know, the CRL contains a list of all revoked certificates for the entire life of the CA, and at some point with the intensive revocation of certificates, its size can reach impressive sizes (several megabytes). It has already been noted above that 100k revoked certificates will be about 9MB in a CRL file. While checking the revocation of any certificate using OCSP will take a fixed size of ~ 2.5KB. There is a tangible difference. In practice, often the recall rate is much lower. If we talk about root CAs or CAs of policies, they will have a piece review, and the size of their review list will hardly exceed 1KB.
It should be noted that OCSP can be effective in a situation where there is one verified certificate and many clients who want to verify it. This is a typical SSL / TLS certificate scenario. In this case, each client instead of downloading a conditional 9MB revocation list will spend 2.5KB of OCSP traffic. But in the opposite situation (one server verifies many client certificates) OCSP can cause a significant load on the network. This includes typical corporate network scenarios: client authentication using certificates, such as EAP-TLS authentication on wireless networks and VPNs, Kerberos authentication on domain controllers. Suppose employees come to work and use certificates for authentication on the network (smart cards, certificates on mobile devices) and a domain controller, RADIUS servers are forced to verify each client certificate. To check only 1K certificates, 2.5 MB of traffic will be spent. In this situation, there is no benefit from OCSP, quite the contrary.
This aspect is taken into account in the logic of Microsoft products. If for a certain period of time the Crypto API client checks 50 (this value can be configured) certificates from one publisher using OCSP, then the work with OCSP ends and the client downloads and caches the CRL for this publisher. More detailed information on this behavior may be found in the section Optimizing the Revocation Experience document Certificate Revocation Checking in Windows Vista and Windows Server 2008 .
Certificate issuance policies are one of the most difficult to understand aspects of certificates and are often completely ignored by administrators when planning and deploying PKIs in an enterprise. However, understanding and the ability to manage issuing policies gives us a more flexible system, an additional level of control and, ultimately, as a method for describing and documenting PKI.
First you need to enter a definition of certificate issuing policies. Any process of issuing / obtaining a certificate is essentially a contract between the recipient of the certificate and the issuing CA. This contract defines many aspects, such as the procedure for issue, use and area of responsibility.
Each company may have different methods for verifying applications and issuing certificates. Consider several typical cases:
All of these scenarios have a distinct difference in the order in which certificates are issued. In one case, it is enough to register in the system, and you can immediately get a certificate. In another case, it is necessary to go through the approval procedure of the application, in the third - the personal presence of the applicant is necessary, etc. Also, the policy defines the rules for using the received certificate, the procedure for updating or revoking the certificate, and actions in unusual situations (for example, in case of loss or theft of a certificate with keys).
These differences in procedures are the issuance policies, and these policies must be recorded in certificates. Target applications can use issuance policies to determine access to a resource. The most famous examples of such applications are Network Policy Server (NPS) andActive Directory Dynamic Access Control . For example, all company employees can connect using certificates to the company's wireless network. But there may be wireless networks, access to which will be allowed only when using certificates on smart cards.
In NPS, you can configure a rule that not only a certificate of entry will be accepted, but one that was issued in accordance with the certificate issuing policy for smart cards. Since this information is reflected in the certificate, NPS can distinguish between two similar certificates (both for user authentication) by issuing policies. If the certificate does not contain evidence that it was issued in accordance with the specified issuance policy, then access to the network will not be allowed. A similar principle is laid down in Active Directory Dynamic Access Control, where you can specify criteria for different access levels.
Issuing policies simply outline the set of procedures and processes that are performed when issuing certificates. It should be understood that the program code does not check in any way whether these procedures were actually followed or not. If at the code level it is impossible to verify their implementation, then why are they? There are two answers to this question.
The first is that a number of IT processes cannot be tracked at the software level. They are checked for compliance with accepted rules by an audit conducted by people. Most often, third-party organizations with competence in the issues under consideration act as auditors. This also applies to certificate issuing policies. In particular, when creating trust (at the PKI and certificates level) between organizations, they provide documents describing the processes and order a third-party audit to verify that these processes are being followed.
The second answer follows from the first: a description of the policies for issuing certificates will ultimately become documentation for the entire PKI and will have its own corporate name - Certificate Practice Statementor CPS (unfortunately, I did not find a suitable term in Russian, so I will use the English abbreviation). To unify the description of issuing policies, there is a recommended (but not mandatory) template described in RFC 3647 . In fact, this document is a policy writing framework and covers all sorts of aspects of PKI. It is not necessary to describe all available sections in a document. You can only document what is applicable to your situation, or add something of your own.
In general, a CPS will consist of two parts:
In the process of compiling the CPS, one or more unique issuance policies will be defined (at least one will be required). Each issuance policy must have a unique identifier and a pointer to the CPS (hyperlink or text string).
Policy IDs must be in ITU-T and ISO format. At one time, I wrote a short introductory article about object identifiers: What is mine in OID? It contains information on how to get your branch of identifiers in IANA (Internet Assigned Numbers Authority). Having received your branch, you select a subset of identifiers for issuing policies inside it, for example: 1.3.6.1.4.1.x.1, where x is the unique identifier of the company registered in IANA. And in it you register specific issuance policies:
Next, you designate specific issuance policies for the CA that will support them. For example, you may have several publishing CAs, each of which will support only certain policies. The list of supported policies will be contained in the Certificate Policies extension of the CA certificate, as well as in end-user certificates.
For example, the picture shows a DigiCert certificate issued in accordance with the issuance policy under the identifier 2.16.840.1.114412.2.1 (in this case, Extended Validation ) and 2.23.140.1.1 (indicates that the CA issues certificates in accordance with CAB / Forum rules) and with reference to CPS. This link allows you to download the latest version of their CPS and familiarize yourself with the conditions for obtaining and using certificates.
When all policies are defined, they are assigned identifiers and pointers are defined, this information is placed in the CA installation configuration file so that this information appears in the certificate. To include information on the policies for issuing end certificates, you must configure certificate templates and specify specific issuance policies for each template. Moreover, if some policy is included in the final certificate, its identifier must be presented both in the final certificate and in all intermediate certificates of the chain (except the root CA). You can read more about this in the articles of my blog: Certificate Policies extension - all you should know (part 1) and Certificate Policies extension - all you should know (part 2). These articles cover general issues related to issuance policies, rules for verifying them in certificate chains, and how to incorporate them into Windows-based certificates.
There is one subtle point here: a CA certificate is issued for a rather long period of time (10 years or more), and when adding or removing issuing policies on a particular CA, you need to re-issue the CA certificate itself, which complicates the process of managing the CA and increases administrative costs. There is no way to describe a group of policies with a single identifier (for example, a company identifier), since masks are not supported. In RFC 5280 §4.2.1.4 provided global identifier (global wildcard) anyPolicy = 2.5.29.32.0, which covers any issuing policies.
Technically, you can use this identifier alone in a CA certificate, then this CA can issue certificates for any policies. Its use is not recommended since during an audit, it is impossible to determine for which specific policies the certificates are issued on a particular CA and, if an external audit is to be conducted, it is quite possible that there may be a claim to anyPolicy identifier, which will entail the need to specify policies explicitly. But this very much depends on local conditions, therefore, at an early stage, you can use this identifier in the CA certificate and already specify specific issuance policies in the final certificates. For these articles, I will use anyPolicy in the certificate of the issuing CA.
AD CS Certificate Services is generally undemanding for hardware resources (compared to other server services). The main load falls on the central processor to perform cryptographic operations (hashing, encryption and signature). In addition, there is a certain disk load for the operation of the certificate database (AD CS uses the JET Database Engine). This is in theory.
In practice, hardware resources, even budget line-ups of servers will be more than enough for the functioning of certificate services, since real needs are very small against the background of OS requirements for hardware resources. Evaluating CA Capacity, Performance, and Scalability was written in the Windows Server 2003 era.(link to the archive copy, as the original has been removed from TechNet), highlighting the general points that need to be considered when planning hardware resources. The article is somewhat outdated (for example, the limit on the number of issued certificates in the context of the database is significantly increased), but the general characteristics have changed little.
In 2010, the Windows PKI Team conducted performance tests using more modern hardware (2007) running Windows Server 2008. The results can be found on their blog: Windows CA Performance Numbers. The data in these articles suggests that the AD CS server on the 2007 hardware server lets you issue about 150 certificates per second. The real need for the speed of issuing certificates is orders of magnitude lower. Therefore, for general purpose CAs, I advise you to focus on the recommended hardware requirements for the OS itself. This applies to both the root and the issuing CA. Therefore, I will list here the requirements for Windows Server 2016 ( Windows Server 2016 System Requirements ):
It should be noted that in the configuration for the root CA there will be no (or should be disconnected) network interface (since it will not be connected to the network) and at least one interface for removable media will be present.
Based on the results of planning, it is very useful to logically group and visualize the main components (and their values) that will need to be configured during the deployment process. You can use various formats, for example, tables. The data from these tables will be used in configuration files and scripts.
To install and create a root CA, you will need to define and configure the certificate and CA server parameters in accordance with the values in the following table.
* - manually copied to the IIS server.
A similar table is compiled for the issuing CA.
As I noted, these tables will be used to compile configuration files and scripts. Once installed, they can be used to verify that all actual configuration values are as planned.
Vadim Podans is a PowerShell and Public Key Infrastructure automation specialist, Microsoft MVP: Cloud and Datacenter Management since 2009, and author of the PowerShell PKI module. For 9 years in his blog he covers various issues of operation and automation of PKI in the enterprise. Vadim's articles on PKI and PowerShell can be found on his website .
Part One Series
Part Three
Introduction
Glossary of Terms
The following abbreviations and abbreviations are used in this part of the series:
- PKI ( Public Key Infrastructure ) - a public key infrastructure, a set of tools (technical, material, human, etc.), distributed services and components, used together to support crypto tasks based on private and public keys. Since the abbreviation PKI is not common, hereinafter, the more familiar English abbreviation PKI will be used.
- X.509 is the ITU-T standard for public key infrastructure and privilege management infrastructure.
- CA ( Certification Authority ) - a service issuing digital certificates. A certificate is an electronic document confirming that the public key belongs to the owner.
- CRL ( Certificate Revocation List ) - A certificate revocation list. A signed electronic document published by the CA and containing a list of revoked certificates whose validity has been terminated due to external reasons. For each revoked certificate, its serial number, date and time of revocation, as well as the reason for revocation (optional) are indicated. Applications can use the CRL to confirm that the presented certificate is valid and not revoked by the publisher ... Applications can use the CRL to confirm that the presented certificate is valid and not revoked by the publisher.
- SSL ( Secure Sockets Layer ) or TLS ( Transport Layer Security ) is a technology that ensures the security of data transfer between the client and server over open networks.
- HTTPS ( HTTP / Secure ) - secure HTTP, is a special case of using SSL.
- Internet PKI is a set of standards, agreements, procedures and practices that provide a single (unified) mechanism for protecting data transmission based on the X.509 standard over open data transmission channels.
- CPS ( Certificate Practice Statement ) is a document that describes the procedures for managing the public key infrastructure and digital certificates.
General Planning Issues
Successful implementation of any technical solution requires careful planning. PKI implementation is no exception. Moreover, if in certain cases the errors of the initial planning can be fixed relatively quickly and easily, then in PKI this is definitely not the case. As I already noted, PKI services are designed to work for many years with minimal (or non-critical) changes in the course of work.
For example, the validity of CA certificates is about 10-20 years. One of the reasons for such a long lifespan is that re-issuing these certificates is a somewhat time-consuming operation and may require changes to a large number of customers. This is compounded by the fact that changes will be required on clients that you may not have access to. Another point is that when you make some changes to the PKI architecture, you will need to maintain the current configuration for the lifetime of the issued certificates. In other words, a new configuration will work for new certificates, but in parallel with it, it will be necessary to maintain the previous configuration so that already issued certificates can work correctly. This also adds to the difficulty of maintaining PKI in a healthy state.
Given these points, PKI planning should be approached in the most serious way. And only then PKI will successfully fulfill its functions in ensuring digital security for a long time.
The multi-stage planning process is based on the logical diagram of the selected model. At each stage, the elements of the diagram are expanded (detailed) and for it the connections, tasks and requirements are formalized. If necessary, detailing continues until a fully formalized system is obtained. This article demonstrates an example of this planning approach.
PKI charting
As I said, it all starts with a logical diagram of the selected model. The logic diagram displays all the PKI components and it should be shifted to the physical topology. In the case of applying the two-level PKI model, such a diagram can have the following form:
The diagram shows the following components and their logical connections:
- Root CA — issues a certificate only to a subordinate CA and publishes its certificate and revocation lists to the revocation server;
- Subordinate (intermediate) CA - issues certificates to end users and publishes its certificate and revocation lists to the revocation server. At the same time, it downloads the root CA revocation list from the revocation server;
- Revocation server - is a repository of CA certificates and their revocation lists, which can be downloaded by any client;
- Client connections - receive their certificates from a subordinate CA and download revocation lists from the revocation server.
The physical topology will be slightly different and have the following form:
The physical topology explicitly emphasizes that the revocation server is available to all clients, both inside and outside the network, so that clients can verify certificates anywhere.
Planning for CA Names
The name of the CA is the name that will be displayed in the
Subject specific CA field . Not to be confused with the host name of the certificate service. The full name of the CA will consist of two components, the name itself (CN attribute or Common Name) and an optional suffix in X.500 format. By default, ADCS assigns a name in the following format: For Standalone CA: <
ComputerName> - CAFor Enterprise CA: <
DomainShortName> - < ComputerName> - CA,< X500DomainSuffix>Is this good or bad? Technically, you can choose any name, functionally it will not affect anything. It is believed that the name of your CA is in some way the visiting card of your PKI, reflecting your attitude to details that are not directly related to functionality, but provide a sufficient level of information and openness. Therefore, when choosing the full name of the certificate, you should be guided by several recommendations:
- The name should reflect the name of the organization (possibly abbreviated) and the role of a particular CA in the hierarchy (attribute CN, Common Name);
- The suffix should reflect the name of the department or unit that is responsible for its management in the OU (Organizational Unit) attribute;
- Duplicate the full name of the organization (attribute O, Organization);
- The legal location of the CA. To do this, it is enough to use the attributes L (Locality) and C (Country). As a rule, this is the name of the city and country where the organization is legally registered. If necessary, you can specify the state / region using the S (State) attribute.
Suppose you select a name for the root CA of the company Contoso Pharmaceuticals Ltd., which is located in Riga, Latvia, and the management is provided by the information technology department. In this case, the name of the CA may be as follows:
CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LVKeep in mind that the Country attribute only supports the two-letter country index. For example, LV, GB, RU, US, etc. As additional examples, you can turn to the CA certificates of commercial providers like VeriSign / Symantec, DigiCert, etc. For a subordinate CA, this name will be similar, except that the word Root in the name will be replaced by Subordinate or Issuing. In the case of a three-level hierarchy, where the policy CA is clearly allocated, the word Root will be replaced by Policy. As I noted above, other rules may apply in your company, and you can implement them in the names of the CAs, this will not affect the functionality. In doing so, avoid:
- Excessively long names in the CN attribute (max 50 characters). If the CN attribute is longer than 51 characters, it will be shortened by docking the hash of the discarded fragment of the name at the end of the name. This is called the name “sanitation” process, which is described in §3.1.1.4.1.1 of the protocol [ MS-WCCE ]. Those. it may happen that if the name is too long, the word will break in the middle and will have an unsightly appearance.
- Use letters that are not part of the Latin alphabet, i.e. no krillitsa or dialectic letters (for example, ā, ž, Ü, ẞ). ADCS only supports single-byte encodings for the CN attribute and for a limited character set. Unsupported characters will be converted to another encoding and become unreadable. A complete list of prohibited characters is provided in §3.1.1.4.1.1.2 of the [ MS-WCCE ] protocol . The principle “the best is the enemy of the good” works here, so the names should be concise and informative enough.
Planning Review Lists (CRLs)
According to the logical diagram, each CA will publish its review list. Our review lists will be characterized by two main categories:
- Points of publication and distribution of recall lists;
- Composition and validity of recall lists.
Review List Publishing and Distribution Points
To publish revocation lists, two types of CRL distribution points are used: the publishing point (where the physical file will be written) and the distribution point (receiving) of the file.
The first type of points indicates the local or network path (in UNC format) where the file will be written. The second type of points will be registered in the issued certificates indicating the way in which customers can download the review list. These paths are published in the CRL Distribution Points certificate extension. These paths will generally not match (except for LDAP, where the publishing and distribution paths are the same). In determining the points of publication should be guided by the following rules:
- For the root CA, a strictly local path is specified, since this server will be isolated from the network. Copying the file to the distribution server (IIS) will be done manually. This is not a problem, since the frequency of publishing review lists for the root CA will be measured in months (see below for more on this).
- For issuing CAs, the network path is indicated. I recommend creating a shared folder in DFS, which can easily be defined as a virtual directory in IIS. In this case, the process of publishing a physical file to the distribution point will be fully automated.
- LDAP should not be used to publish and distribute revocation lists.
For more information on planning the CRL Distribution Points and Authority Information Access extensions and practices, see my blog post: Designing CRL Distribution Points and Authority Information Access locations .
Review List Composition
Before planning the composition and validity of recall lists, it is necessary to understand the purpose of recall lists and the optimal parameters depending on their operating conditions. As you know, each CA periodically publishes review lists, which include lists of all certificates revoked by a particular CA. Moreover, each list includes all revoked certificates for the entire life of the CA. With a CA lifespan of, for example, 10 years, this list can grow to an impressive size (of the order of several megabytes).
Even with high-speed connections, revocation list traffic will be significant in size because all certificate consumers need the latest revision list.
To reduce the traffic of revocation lists, two types of CRLs are to be published: Basic (Base CRL) and differential (Delta CRL). The base list includes a complete review list. The differential list includes only the list of revoked certificates that have been revoked since the last publication of the base CRL. This allows you to publish the basic list less often and for a longer period, and to speed up the response time of clients to the revoked certificates in the interval to issue several short-lived differential CRLs.
The selection of parameters depends on several factors. For example, the planned volume of issued certificates and the planned volume of revocation. Consider typical scenarios.
Root CA
The root CA issues certificates only to intermediate CAs, the number of which is usually within a dozen. The validity period of intermediate CAs is comparable to the lifetime of the root CA certificate. It is also assumed that the risk of recalling subordinate CAs is very low, since they are managed by trained personnel and appropriate security measures are in place. Therefore, it can be argued that the volume of the revocation list can include only a small number of revoked certificates and, accordingly, the CRL file will be guaranteed to be small in size.
Help: how to calculate the planned size of the CRL file based on the size of the review? A typical empty CRL takes approximately 600-800 bytes. Each certificate revocation record is 88 bytes. Based on these values, you can calculate the CRL size depending on the number of revoked certificates.
It follows that throughout the life of the root CA, the recall list will be within 1kb and there is no point in differential CRL.
Publishing CA
For the publisher CA, the picture is changing. The volume of issued certificates is already high, it can be thousands and millions of pieces. Consumers are users and devices that are at high risk of recall because they are not constantly monitored by qualified personnel and it is not possible to provide appropriate measures. As a result, the review list can reach serious sizes. For example, if you put a 10% risk of revocation, then for a million issued certificates there are about 100k revoked. 100k records of 88 bytes will be a little less than 10mb. It is often not very practical to update the file by 10mb, it is more expedient to publish it less often, and to distribute several lightweight differential Delta CRLs in the interval between publications of the main CRL. Those. if for the root CA only the basic revocation list is sufficient, then for the CA,
CRL Expiration Planning
It was all about the composition of the review lists for each CA. Now you should determine the timing:
- How long should a review list be published?
- How long can the information in it be considered reliable and sufficiently relevant?
Here, you can also apply the approach depending on the operating conditions. The risk of revoking an intermediate CA is very low, therefore, it makes no sense to publish an empty CRL too often. In modern practice, the following typical values for the CRL validity period for CAs are used, which issue certificates only to other CAs: 3, 6, or 12 months. It should be based on the degree of risk and administrative costs of maintaining recall lists. If there are no special conditions, then I recommend choosing something average, about 6 months.
For subordinate CAs, the scheme is the same. Since the risk of revoking client certificates is high, we can assume a high frequency of revocation. Therefore, such a CA should publish review lists much more often, and to save traffic, combine basic and differential CRLs. By default, Microsoft CA publishes revocation lists with the following frequency: basic CRL once a week, deltas daily. In this situation, customers will be notified of the latest revoked certificates within 24 hours.
You can understand the desire of administrators to reduce this time (ideally - instantly) so that customers do not recognize the revoked certificate as valid. However, a decrease in one risk leads to an increase in another risk. Imagine, for some reason, the CA server failed when the previous CRL was close to expiration and the new CRL could not be published. Then the problems will begin with checking certificate revocation and stopping them until the CA server is restored to work. This point must be taken into account when setting the expiration dates for review lists.
Microsoft CA, by default, already lays down some time reserve for unforeseen cases, and when it takes some time to distribute review lists to all publication points (for example, caused by latency of replication). This reserve in English terminology is called CRL overlap. The idea behind the defense mechanism is that the CA generates and publishes review lists before the expiration of the previous published list.
This is achieved by using two fields in the review list: Next CRL Publish and Next Update. The Next CRL Publish field indicates the time when the CA publishes an updated revocation list (automatically). Next Update indicates the time when the current list expires. The Next Update field will always be set a little later than Next CRL Publish. In other words, the CA will publish an updated revocation list before the expiration of the previous one. The algorithm for calculating automatic values for these fields is nontrivial and is described in the following article: How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). If the default values do not suit you for one reason or another, you can edit them. It should be borne in mind that the time margin has lower and upper boundaries. For example, the upper bound cannot exceed the validity period of the CRL itself. So, if the validity period of the CRL is 1 day, then the stock can be a maximum of 1 day, and then the CA will publish review lists daily, but the validity period will be 2 days. Thus, a margin of time is achieved for the restoration of the CA in case of unforeseen circumstances.
In practice, I quite often observed the desire of administrators to twist the CRL expiration settings to the minimum limit with the following rationale: "the user quit and should not be able to authenticate with the revoked certificate." The motivation is understandable, but solving the problem through review lists is not entirely correct. In case the user needs to stop access to corporate systems, it is necessary to disable the user account or computer.
When planning your CRL expiration dates and frequency, you should be guided by the following recommendations:
- All CAs that issue certificates only to other CAs (not end users) must publish CRLs for a period of 3 to 12 months with a margin of one month.
- All CAs that issue certificates to end users (users and devices) must publish basic CRLs at least once a week and differential lists at least 3 days (preferably daily). The time margin should not be adjusted (use the one that will be automatically calculated by the internal logic of the CA).
Online Certificate Status Protocol
As part of this article series, I will not use OCSP servers for an additional method of distributing information about revoked certificates. If you wish, you can refer to the comprehensive TechNet article: Online Responder Installation, Configuration, and Troubleshooting Guide . As practice shows, in most cases, the installation and support of OCSP is not justified for several reasons.
The main goal of OCSP is to offload CRL download traffic. As you know, the CRL contains a list of all revoked certificates for the entire life of the CA, and at some point with the intensive revocation of certificates, its size can reach impressive sizes (several megabytes). It has already been noted above that 100k revoked certificates will be about 9MB in a CRL file. While checking the revocation of any certificate using OCSP will take a fixed size of ~ 2.5KB. There is a tangible difference. In practice, often the recall rate is much lower. If we talk about root CAs or CAs of policies, they will have a piece review, and the size of their review list will hardly exceed 1KB.
It should be noted that OCSP can be effective in a situation where there is one verified certificate and many clients who want to verify it. This is a typical SSL / TLS certificate scenario. In this case, each client instead of downloading a conditional 9MB revocation list will spend 2.5KB of OCSP traffic. But in the opposite situation (one server verifies many client certificates) OCSP can cause a significant load on the network. This includes typical corporate network scenarios: client authentication using certificates, such as EAP-TLS authentication on wireless networks and VPNs, Kerberos authentication on domain controllers. Suppose employees come to work and use certificates for authentication on the network (smart cards, certificates on mobile devices) and a domain controller, RADIUS servers are forced to verify each client certificate. To check only 1K certificates, 2.5 MB of traffic will be spent. In this situation, there is no benefit from OCSP, quite the contrary.
This aspect is taken into account in the logic of Microsoft products. If for a certain period of time the Crypto API client checks 50 (this value can be configured) certificates from one publisher using OCSP, then the work with OCSP ends and the client downloads and caches the CRL for this publisher. More detailed information on this behavior may be found in the section Optimizing the Revocation Experience document Certificate Revocation Checking in Windows Vista and Windows Server 2008 .
Plan certificate issuance policies
Certificate issuance policies are one of the most difficult to understand aspects of certificates and are often completely ignored by administrators when planning and deploying PKIs in an enterprise. However, understanding and the ability to manage issuing policies gives us a more flexible system, an additional level of control and, ultimately, as a method for describing and documenting PKI.
Policy Definition
First you need to enter a definition of certificate issuing policies. Any process of issuing / obtaining a certificate is essentially a contract between the recipient of the certificate and the issuing CA. This contract defines many aspects, such as the procedure for issue, use and area of responsibility.
Each company may have different methods for verifying applications and issuing certificates. Consider several typical cases:
- Certificates for signing an e-mail can be issued automatically with a minimum verification of the applicant (only on the basis of successful authentication of the user in Active Directory). No further action is taken to issue these certificates.
- Certificates for digital signing of documents can be issued only after agreement with the immediate supervisor and the provision of a written application with all the necessary signatures.
- Certificates for smart cards can be issued only with the personal presence of the employee, along with instructions on the rules for using cards, signing of relevant regulatory documents.
- All users can obtain an authentication certificate for accessing a wireless network from mobile devices, but access to critical systems will be allowed if authentication was performed only using smart cards.
All of these scenarios have a distinct difference in the order in which certificates are issued. In one case, it is enough to register in the system, and you can immediately get a certificate. In another case, it is necessary to go through the approval procedure of the application, in the third - the personal presence of the applicant is necessary, etc. Also, the policy defines the rules for using the received certificate, the procedure for updating or revoking the certificate, and actions in unusual situations (for example, in case of loss or theft of a certificate with keys).
These differences in procedures are the issuance policies, and these policies must be recorded in certificates. Target applications can use issuance policies to determine access to a resource. The most famous examples of such applications are Network Policy Server (NPS) andActive Directory Dynamic Access Control . For example, all company employees can connect using certificates to the company's wireless network. But there may be wireless networks, access to which will be allowed only when using certificates on smart cards.
In NPS, you can configure a rule that not only a certificate of entry will be accepted, but one that was issued in accordance with the certificate issuing policy for smart cards. Since this information is reflected in the certificate, NPS can distinguish between two similar certificates (both for user authentication) by issuing policies. If the certificate does not contain evidence that it was issued in accordance with the specified issuance policy, then access to the network will not be allowed. A similar principle is laid down in Active Directory Dynamic Access Control, where you can specify criteria for different access levels.
Policy Description
Issuing policies simply outline the set of procedures and processes that are performed when issuing certificates. It should be understood that the program code does not check in any way whether these procedures were actually followed or not. If at the code level it is impossible to verify their implementation, then why are they? There are two answers to this question.
The first is that a number of IT processes cannot be tracked at the software level. They are checked for compliance with accepted rules by an audit conducted by people. Most often, third-party organizations with competence in the issues under consideration act as auditors. This also applies to certificate issuing policies. In particular, when creating trust (at the PKI and certificates level) between organizations, they provide documents describing the processes and order a third-party audit to verify that these processes are being followed.
The second answer follows from the first: a description of the policies for issuing certificates will ultimately become documentation for the entire PKI and will have its own corporate name - Certificate Practice Statementor CPS (unfortunately, I did not find a suitable term in Russian, so I will use the English abbreviation). To unify the description of issuing policies, there is a recommended (but not mandatory) template described in RFC 3647 . In fact, this document is a policy writing framework and covers all sorts of aspects of PKI. It is not necessary to describe all available sections in a document. You can only document what is applicable to your situation, or add something of your own.
In general, a CPS will consist of two parts:
- Description of PKI hierarchies common to all procedures and provisions that will be common to all specific issuance policies.
- Description of provisions specific to a specific extradition policy. Depending on the dimension of PKI, its features, a separate CPS may be compiled for each policy, but most often it comes down to compiling a single document that will describe everything.
Policy Programming
In the process of compiling the CPS, one or more unique issuance policies will be defined (at least one will be required). Each issuance policy must have a unique identifier and a pointer to the CPS (hyperlink or text string).
Policy IDs must be in ITU-T and ISO format. At one time, I wrote a short introductory article about object identifiers: What is mine in OID? It contains information on how to get your branch of identifiers in IANA (Internet Assigned Numbers Authority). Having received your branch, you select a subset of identifiers for issuing policies inside it, for example: 1.3.6.1.4.1.x.1, where x is the unique identifier of the company registered in IANA. And in it you register specific issuance policies:
- 1.3.6.1.4.1.x.1.1
- 1.3.6.1.4.1.x.1.2
- 1.3.6.1.4.1.x.1.3
- 1.3.6.1.4.1.x.1.4
- ...
Next, you designate specific issuance policies for the CA that will support them. For example, you may have several publishing CAs, each of which will support only certain policies. The list of supported policies will be contained in the Certificate Policies extension of the CA certificate, as well as in end-user certificates.
For example, the picture shows a DigiCert certificate issued in accordance with the issuance policy under the identifier 2.16.840.1.114412.2.1 (in this case, Extended Validation ) and 2.23.140.1.1 (indicates that the CA issues certificates in accordance with CAB / Forum rules) and with reference to CPS. This link allows you to download the latest version of their CPS and familiarize yourself with the conditions for obtaining and using certificates.
When all policies are defined, they are assigned identifiers and pointers are defined, this information is placed in the CA installation configuration file so that this information appears in the certificate. To include information on the policies for issuing end certificates, you must configure certificate templates and specify specific issuance policies for each template. Moreover, if some policy is included in the final certificate, its identifier must be presented both in the final certificate and in all intermediate certificates of the chain (except the root CA). You can read more about this in the articles of my blog: Certificate Policies extension - all you should know (part 1) and Certificate Policies extension - all you should know (part 2). These articles cover general issues related to issuance policies, rules for verifying them in certificate chains, and how to incorporate them into Windows-based certificates.
There is one subtle point here: a CA certificate is issued for a rather long period of time (10 years or more), and when adding or removing issuing policies on a particular CA, you need to re-issue the CA certificate itself, which complicates the process of managing the CA and increases administrative costs. There is no way to describe a group of policies with a single identifier (for example, a company identifier), since masks are not supported. In RFC 5280 §4.2.1.4 provided global identifier (global wildcard) anyPolicy = 2.5.29.32.0, which covers any issuing policies.
Technically, you can use this identifier alone in a CA certificate, then this CA can issue certificates for any policies. Its use is not recommended since during an audit, it is impossible to determine for which specific policies the certificates are issued on a particular CA and, if an external audit is to be conducted, it is quite possible that there may be a claim to anyPolicy identifier, which will entail the need to specify policies explicitly. But this very much depends on local conditions, therefore, at an early stage, you can use this identifier in the CA certificate and already specify specific issuance policies in the final certificates. For these articles, I will use anyPolicy in the certificate of the issuing CA.
Hardware Requirements Planning
AD CS Certificate Services is generally undemanding for hardware resources (compared to other server services). The main load falls on the central processor to perform cryptographic operations (hashing, encryption and signature). In addition, there is a certain disk load for the operation of the certificate database (AD CS uses the JET Database Engine). This is in theory.
In practice, hardware resources, even budget line-ups of servers will be more than enough for the functioning of certificate services, since real needs are very small against the background of OS requirements for hardware resources. Evaluating CA Capacity, Performance, and Scalability was written in the Windows Server 2003 era.(link to the archive copy, as the original has been removed from TechNet), highlighting the general points that need to be considered when planning hardware resources. The article is somewhat outdated (for example, the limit on the number of issued certificates in the context of the database is significantly increased), but the general characteristics have changed little.
In 2010, the Windows PKI Team conducted performance tests using more modern hardware (2007) running Windows Server 2008. The results can be found on their blog: Windows CA Performance Numbers. The data in these articles suggests that the AD CS server on the 2007 hardware server lets you issue about 150 certificates per second. The real need for the speed of issuing certificates is orders of magnitude lower. Therefore, for general purpose CAs, I advise you to focus on the recommended hardware requirements for the OS itself. This applies to both the root and the issuing CA. Therefore, I will list here the requirements for Windows Server 2016 ( Windows Server 2016 System Requirements ):
- CPU - dual-core 1.4 GHz;
- Memory - 1GB RAM;
- Disk - 48 GB for the system disk and at least 48 GB for local backups. It is desirable to place the system partition on disks with RAID1.
- Display - SVGA (800 * 600);
- Network - A standard network interface.
It should be noted that in the configuration for the root CA there will be no (or should be disconnected) network interface (since it will not be connected to the network) and at least one interface for removable media will be present.
Final configuration
Based on the results of planning, it is very useful to logically group and visualize the main components (and their values) that will need to be configured during the deployment process. You can use various formats, for example, tables. The data from these tables will be used in configuration files and scripts.
Root CA
To install and create a root CA, you will need to define and configure the certificate and CA server parameters in accordance with the values in the following table.
| Parameter Name | Parameter value |
|---|---|
| CA Server | |
| CA class | Standalone ca |
| Type of CA | Root root |
| Validity of issued certificates | 15 years |
| Publish to AD (containers) | Certification Authorities AIA |
| CRT publishing points | 1) By default 2) C: \ CertData \ contoso-rca 3) IIS: \ InetPub \ PKIdata \ contoso-rca |
| CRT Distribution Points | 1) URL = http: //cdp.contoso.com/pki/contoso-rca |
| CRL Publishing Points | 1) By default 2) C: \ CertData \ contoso-rca 3) IIS: \ InetPub \ PKIdata \ contoso-rca |
| CRL Distribution Points | 1) URL = http: //cdp.contoso.com/pki/contoso-rca |
| Certificate | |
| Certificate name | Contoso Lab Root Certification authority |
| Additional suffix | OU = Division Of IT, O = Contoso Pharmaceuticals, C = US |
| Key provider | RSA # Microsoft Software Key Storage Provider |
| Key length | 4096 bit |
| Signature algorithm | SHA256 |
| Validity | 15 years |
| CRL Composition | Base CRL |
| Base CRL | |
| A type | Base CRL |
| Validity | 6 months |
| Expansion | 1 month |
| Signature algorithm | SHA256 |
| Publish to AD | Not |
Publishing CA
A similar table is compiled for the issuing CA.
| Parameter Name | Parameter value |
|---|---|
| Сервер ЦС | |
| Класс ЦС | Enterprise CA |
| Тип ЦС | Subordinate CA |
| Срок действия издаваемых сертификатов | Максимально: 5 лет (остальное контролируется шаблонами сертификатов) |
| Автоматическая загрузка шаблонов | Нет |
| Публикация в AD (контейнеры) | AIA NTAuthCertificates |
| Состав CRL | Base CRL Delta CRL |
| Точки публикации CRT | 1) По-умолчанию 2) \\IIS\PKI\contoso-pica |
| Точки распространения CRT | 1) URL=http://cdp.contoso.com/pki/contoso-pica |
| Точки публикации CRL | 1) По-умолчанию 2) \\IIS\PKI\contoso-pica |
| Точки распространения CRL | 1) URL=http://cdp.contoso.com/pki/contoso-pica |
| Сертификат | |
| Имя сертификата | Contoso Lab Issuing Certification authority |
| Дополнительный суффикс | OU=Division Of IT, O=Contoso Pharmaceuticals, C=US |
| Провайдер ключа | RSA#Microsoft Software Key Storage Provider |
| Длина ключа | 4096 бит |
| Алгоритм подписи | SHA256 |
| Срок действия | 15 лет (определяется вышестоящим ЦС) |
| Политики выдачи | 1) Name: All Issuance Policies OID = 2.5.29.32.0 URL = http: //cdp.contoso.com/pki/contoso-cps.html |
| Basic constraints | isCA = True (certificate type - CA certificate) PathLength = 0 (creation of other intermediate CAs under the current CA is prohibited). |
| Base CRL | |
| A type | Base CRL |
| Validity | 1 Week |
| Expansion | Default |
| Signature algorithm | SHA256 |
| Publish to AD | Not |
| Delta CRL | |
| A type | Delta CRL |
| Validity | 1 day |
| Expansion | Default |
| Signature algorithm | SHA256 |
| Publish to AD | Not |
IIS server
| Parameter Name | Parameter value |
|---|---|
| CA Server | |
| Web site | cdp |
| Host header | cdp.contoso.com |
| Virtual directories | PKI = C: \ InetPub \ wwwroot \ PKIdata |
| Double escape | Switched on |
As I noted, these tables will be used to compile configuration files and scripts. Once installed, they can be used to verify that all actual configuration values are as planned.
about the author
Vadim Podans is a PowerShell and Public Key Infrastructure automation specialist, Microsoft MVP: Cloud and Datacenter Management since 2009, and author of the PowerShell PKI module. For 9 years in his blog he covers various issues of operation and automation of PKI in the enterprise. Vadim's articles on PKI and PowerShell can be found on his website .