Installation of a certification authority in the enterprise. Part 2
We continue our series of articles about the certification authority in the enterprise. Today we'll talk about building a public key diagram, planning the name of the certification authority, planning certificate revocation lists and a few other points. Join now!
The following abbreviations and abbreviations have been used in this part of the series:
For the successful implementation of any technical solution, careful planning is necessary. PKI implementation is no exception. Moreover, if in certain cases, initial planning errors can be corrected relatively quickly and easily, then this is definitely not the case in PKI. As I have already noted, PKI services are designed to work for many years with minimal (or noncritical) 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 reissuing these certificates is a somewhat time consuming operation and may require changes on a large number of clients. This is aggravated by the fact that changes will be required on clients to whom you may not have access. 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 certificates already issued. In other words, for the new certificates, the new configuration will act, but in parallel with it, it will be necessary to maintain the previous configuration so that the already issued certificates can work correctly. This also adds difficulty in maintaining PKI in a healthy state.
Given these points, planning a PKI should be approached very seriously. And only then will the PKI successfully perform its functions in ensuring digital security over the long term.
The multi-stage planning process is based on a logical diagram of the selected model. At each stage, the elements of the diagram unfold (elaborate) and the relations, tasks and requirements are formalized for it. If necessary, the detailing continues until a fully formalized system is obtained. This article shows an example of such an approach to planning.
As I said, it all starts with a logical diagram of the selected model. The logical diagram displays all the components of the PKI and must be transferred to the physical topology. In the case of the use of a two-tier PKI model, this diagram may have the following form:
The diagram shows the following components and their logical connections:
The physical topology will be slightly different and look like this:
In the physical topology, it is explicitly stated that the revocation server is accessible to all clients, both inside and outside the network, so that clients can check certificates anywhere.
The CA name is the name that will be displayed in the
For Standalone CA: <
For Enterprise CA: <
Is it 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 somewhat of a business card of your PKI, reflecting your attitude to details that are not directly related to the functionality, but provide a sufficient level of information and openness. Therefore, when choosing the full name of the certificate you should follow several recommendations:
Suppose you select a name for the root CA of Contoso Pharmaceuticals Ltd., which you find in Riga, Latvia, and the management is provided by the information technology department. In this case, the name of the CA can be as follows:
Note that the Country attribute only supports a two-letter country index. For example, LV, GB, RU, US, etc. As additional examples, you can refer to 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 CA of the politician is clearly distinguished, the word Root will be replaced with the Policy. As I noted above, other rules may apply in your company, and you can embed them in the names of the CA, this will not affect the functionality. You should avoid:
In accordance with the logical diagram, each CA will publish its own revocation list. Feedback lists will be described in two main categories:
Two types of CRL distribution points are used to publish revocation lists: the publication point (where the physical file will be recorded) and the distribution point (receipt) of the file.
The first point type 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 with an indication of the way in which customers can download the revocation list. These paths are published in the CRL Distribution Points certificate extension. In general, these paths will not be the same (except for the LDAP protocol, where the publication and distribution paths are the same). In determining the points of publication should be guided by the following rules:
You can read more about planning CRL Distribution Points and Authority Information Access extensions and practices in my blog article: Designing CRL Distribution Points and Authority Information Access locations .
Before planning the composition and validity of revocation lists, it is necessary to understand the purpose of revocation lists and the optimal parameters depending on their operating conditions. As you know, each CA periodically publishes lists of reviews, which include lists of all certificates that have been revoked by a specific CA. And each list includes all revoked certificates for the entire CA lifetime. With a CA's lifespan, for example, in 10 years, this list can grow to an impressive size (on the order of several megabytes).
Even with high-speed connections, revocation list traffic will be substantial in size, since all certificate consumers need the latest revocation list version.
To reduce the traffic of revocation lists, two types of CRLs are published: base (Base CRL) and differential (Delta CRL). The basic list includes a complete review list. The differential list includes only a list of revoked certificates that have been revoked since the last publication of the base CRL. This allows you to publish a basic list less frequently and for a longer period, and to speed up customer response times to revoked certificates, in the meantime, 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 withdrawal from downstream CAs is very low, as they are managed by trained personnel and are provided with appropriate security measures. Therefore, it can be argued that the volume of the revocation list may 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 amount of feedback? A typical empty CRL takes about 600-800 bytes. Each certificate revocation entry is 88 bytes. Based on these values, you can calculate the size of the CRL, depending on the number of revoked certificates.
It follows that throughout the lifetime of the root CA, the revocation list will be within 1kb and there is no point in the differential CRL.
Publishing CA
For the publishing CA, the picture changes. The volume of certificates issued is already high, it can be thousands and millions of pieces. Consumers are users and devices that are at high risk of revocation, since they are not under the constant supervision of qualified personnel, and it is impossible to provide adequate measures. As a result, the review list can reach serious sizes. For example, if you lay a 10% risk of revocation, then a million certificates issued account for about 100k revoked. 100k records of 88 bytes will be a little less than 10mb. It is not very practical to update the file on 10mb very often, it is more expedient to publish it less often, and to distribute several lightweight differential Delta CRLs between publications of the main CRL. Those. if only a basic revocation list is sufficient for a root CA, then deltas should be used for CAs issuing certificates to end users.
It was all about the composition of the revocation lists for each CA. Now we need to determine the dates:
Here, too, you can apply the approach depending on the operating conditions. The risk of withdrawing an intermediate CA is very low, therefore, there is no point in publishing an empty CRL too often. In modern practice, the following typical values are applied for the CRL validity period for a CA, which issue certificates only to another CA: 3, 6 or 12 months. Here it is necessary to build on the degree of risk and administrative costs of maintaining the revocation 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 revocation of client certificates is high, one can assume a high revocation rate. Therefore, such CAs should publish revocation lists much more often, and to save traffic, combine basic and differential CRLs. By default, Microsoft CA publishes revocation lists with the following frequency: base 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, reducing one risk leads to an increase in another risk. Imagine that for some reason the CA server failed at a time when the previous CRL was about to expire, and the new CRL could not be published. Then problems will begin with checking certificate revocation and stopping them until the CA server is restored. This point must be taken into account when setting the validity of revocation lists.
Microsoft CA by default already lays some time reserve for emergencies and when distributing revocation lists to all publishing points takes some time (for example, caused by replication latency). This reserve in English terminology is called CRL overlap. The idea behind the defense mechanism is that the CA generates and publishes revocation lists before the previous published list expires.
This is achieved using two fields in the revocation list: Next CRL Publish and Next Update. The Next CRL Publish field indicates the time when the CA publishes the updated revocation list (automatically). Next Update indicates the time when the current list will expire. The Next Update field will always be set a little later than the Next CRL Publish. In other words, the CA will publish an updated revocation list before the previous one expires. The algorithm for calculating automatic values for these fields is non-trivial 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 is necessary to take into account that the time reserve has lower and upper bounds. For example, the upper bound cannot exceed the validity period of the CRL itself. So, if the CRL validity period is 1 day, then the stock can be a maximum of 1 day, and then the CA will publish revocation lists daily, but the validity period will be 2 days. Thereby, a time margin for restoring the CA in case of unforeseen circumstances is achieved.
In practice, I quite often observed the desire of administrators to tighten the CRL expiration settings to the minimum limit with the following rationale: “the user left and should not be able to authenticate with a revoked certificate”. The motivation is understandable, but solving the problem through revocation 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 the CRL validity and periodicity, the following guidelines should be followed:
Within this series of articles, 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 article on TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide . As practice shows, in most cases, installation and support of OCSP is not justified for several reasons.
The main task of OCSP is to offload CRL download traffic. As you know, the CRL contains a list of all revoked certificates for the entire CA lifetime, and at some point with intensive revocation of certificates, its size can reach impressive sizes (several megabytes). As noted above, 100k revoked certificates will be about 9MB in the 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, the response rate is often much lower. If we talk about root CA or CA policy, they will have a piece of feedback, 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 verifiable certificate and many clients that want to verify it. This is a typical SSL / TLS certificate script. In this case, each client will spend 2.5KB of OCSP traffic instead of downloading a conditional 9MB revocation list. But in the opposite situation (one server verifies a lot of client certificates) OCSP can cause significant network load. This includes typical corporate network scenarios: client authentication using certificates, such as EAP-TLS authentication in wireless networks and VPN, Kerberos authentication on domain controllers. Suppose employees come to work and use certificates for network authentication (smart cards, certificates on mobile devices) and a domain controller, RADIUS servers are forced to verify each client certificate. To check only 1K certificates will be spent 2.5MB of traffic. 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 within a certain period of time, the Crypto API client checks 50 (this value can be configured) certificates from one publisher using OCSP, then this ends the work with OCSP and the client downloads and caches the CRL for that publisher. You can learn more about this behavior in the Optimizing the Revocation Experience section of the Certificate Revocation Checking in Windows Vista and Windows Server 2008 document.
Certificate issuance policies are one of the most difficult to understand aspects of certificate operation and are often completely ignored by administrators when planning and deploying PKI in an enterprise. However, the understanding and ability to manage issuance policies gives us a more flexible system, an additional level of control, and ultimately, a method of describing and documenting PKI.
First you need to enter the definition of certificate issuance policies. Any process of issuing / receiving a certificate is essentially a contract between the certificate recipient and the issuing CA. This contract defines many aspects, such as issuance, use, and areas of responsibility.
Each company may have different methods for checking applications and issuing certificates. Consider a few typical cases:
. , . , — .. , , (, ).
, . . Network Policy Server (NPS) Active Directory Dynamic Access Control . , . , -.
NPS , , , -. , NPS ( ) . , , . Active Directory Dynamic Access Control, .
, . , , . , ? .
, - . , . , . . , ( PKI ) , , , .
: PKI – Certificate Practice Statement CPS ( , , ). ( ) , RFC 3647 . , PKI. . , , - .
CPS :
CPS ( ). CPS ( ).
ITU-T ISO. : OID' ? , IANA (Internet Assigned Numbers Authority) . , , : 1.3.6.1.4.1.x.1, x – , IANA. :
, . , , . Certificate Policies , .
, DigiCert, 2.16.840.1.114412.2.1 ( Extended Validation ) 2.23.140.1.1 (, CAB/Forum) CPS. CPS .
, , , . . , - , , ( ). : Certificate Policies extension – all you should know (part 1) Certificate Policies extension – all you should know (part 2) . , , Windows.
: (10 ) , . (, ), . RFC 5280 §4.2.1.4 (global wildcard) anyPolicy = 2.5.29.32.0, .
, , . , .. , , , , anyPolicy , . , . anyPolicy .
AD CS ( ). (, ). , (AD CS JET Database Engine). This is in theory.
, . Windows Server 2003 Evaluating CA Capacity, Performance, and Scalability ( , .. TechNet), , . (, ), .
2010 , Windows PKI Team ( 2007 ) Windows Server 2008. : Windows CA Performance Numbers . , , AD CS 2007 150 . . . , . Windows Server 2016 ( Windows Server 2016 System Requirements ):
, ( ) ( ) .
( ), . , , . .
.
* — IIS .
.
, . , .
— PowerShell Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management 2009 PowerShell PKI. 9 PKI . PKI PowerShell .
The first part of the series
')
Third part of the series
Introduction
Glossary
The following abbreviations and abbreviations have been used in this part of the series:
- PKI ( Public Key Infrastructure ) is 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, hereafter, the more familiar English-language abbreviation PKI will be used.
- X.509 is the ITU-T standard for public key infrastructure and privilege management infrastructure.
- CA ( Certification Center ) - a service that issues digital certificates. A certificate is an electronic document confirming that the public key belongs to the owner.
- CRL ( Certificate Revocation List ) - certificate revocation list. A signed electronic document published by the CA and containing a list of revoked certificates whose validity was 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 certificate presented is valid and not revoked by the publisher ... Applications can use the CRL to confirm that the certificate presented 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 transmission between a client and a 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) data transmission protection mechanism based on the X.509 standard over open data transmission channels.
- CPS ( Certificate Practice Statement ) is a document that describes the procedures for managing public key infrastructure and digital certificates.
General planning issues
For the successful implementation of any technical solution, careful planning is necessary. PKI implementation is no exception. Moreover, if in certain cases, initial planning errors can be corrected relatively quickly and easily, then this is definitely not the case in PKI. As I have already noted, PKI services are designed to work for many years with minimal (or noncritical) 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 reissuing these certificates is a somewhat time consuming operation and may require changes on a large number of clients. This is aggravated by the fact that changes will be required on clients to whom you may not have access. 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 certificates already issued. In other words, for the new certificates, the new configuration will act, but in parallel with it, it will be necessary to maintain the previous configuration so that the already issued certificates can work correctly. This also adds difficulty in maintaining PKI in a healthy state.
Given these points, planning a PKI should be approached very seriously. And only then will the PKI successfully perform its functions in ensuring digital security over the long term.
The multi-stage planning process is based on a logical diagram of the selected model. At each stage, the elements of the diagram unfold (elaborate) and the relations, tasks and requirements are formalized for it. If necessary, the detailing continues until a fully formalized system is obtained. This article shows an example of such an approach to planning.
PKI Plotting
As I said, it all starts with a logical diagram of the selected model. The logical diagram displays all the components of the PKI and must be transferred to the physical topology. In the case of the use of a two-tier PKI model, this diagram may 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 (Revocation Server);
- Slave (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 revocation list of the root CA from the revocation server;
- Revocation Server - is a repository of CA certificates and revocation lists that any client can download;
- Client connections - get their certificates from a subordinate CA and download revocation lists from the revocation server.
The physical topology will be slightly different and look like this:
In the physical topology, it is explicitly stated that the revocation server is accessible to all clients, both inside and outside the network, so that clients can check certificates anywhere.
CA Name Planning
The CA name is the name that will be displayed in the
Subject field of a specific CA. Not to be confused with the name of the host on which the certificate service is running. The full name of the CA will consist of two components, the name itself (CN attribute or Common Name) and an optional X.500 suffix. By default, ADCS assigns a name in the following format:For Standalone CA: <
ComputerName > - CAFor Enterprise CA: <
DomainShortName > - < ComputerName > - CA, < X500DomainSuffix >Is it 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 somewhat of a business card of your PKI, reflecting your attitude to details that are not directly related to the functionality, but provide a sufficient level of information and openness. Therefore, when choosing the full name of the certificate you should follow several recommendations:
- The name should reflect the name of the organization (it can be abbreviated) and the role of the specific CA in the hierarchy (attribute CN, Common Name);
- The suffix should reflect the name of the department or division that is responsible for its management in the attribute OU (Organizational Unit);
- Duplicate the full name of the organization (attribute O, Organization);
- Legal location of the CA. For 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 attribute (State).
Suppose you select a name for the root CA of Contoso Pharmaceuticals Ltd., which you find in Riga, Latvia, and the management is provided by the information technology department. In this case, the name of the CA can be as follows:
CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV Note that the Country attribute only supports a two-letter country index. For example, LV, GB, RU, US, etc. As additional examples, you can refer to 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 CA of the politician is clearly distinguished, the word Root will be replaced with the Policy. As I noted above, other rules may apply in your company, and you can embed them in the names of the CA, this will not affect the functionality. You should avoid:
- Excessively long names in the CN attribute (no more than 50 characters). If the length of the CN attribute is over 51 characters, it will be shortened with the hash attachment of the discarded name fragment to the end of the name. This is called the sanitizing process of the name, which is described in §3.1.1.4.1.1 of the [ MS-WCCE ] protocol. Those. it may happen that if the name is too long, the word will break off in the middle and will have an unsightly appearance.
- Use letters that are not part of the Latin alphabet, i.e. no krillitsy or diacritical letters (for example, ā, ž, Ü, ẞ). ADCS only supports single-byte character encodings for the CN attribute and for a limited set of characters. Unsupported characters will be converted to another encoding and will 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 of “the best is the enemy of the good” works here, so the names should be sufficiently concise and informative.
Scheduling Call List (CRL)
In accordance with the logical diagram, each CA will publish its own revocation list. Feedback lists will be described in two main categories:
- Points of publication and distribution of revocation lists;
- Composition and validity of revocation lists.
Points of publication and distribution of revocation lists
Two types of CRL distribution points are used to publish revocation lists: the publication point (where the physical file will be recorded) and the distribution point (receipt) of the file.
The first point type 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 with an indication of the way in which customers can download the revocation list. These paths are published in the CRL Distribution Points certificate extension. In general, these paths will not be the same (except for the LDAP protocol, where the publication 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 publication of revocation 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.
You can read more about planning CRL Distribution Points and Authority Information Access extensions and practices in my blog article: Designing CRL Distribution Points and Authority Information Access locations .
The list of reviews
Before planning the composition and validity of revocation lists, it is necessary to understand the purpose of revocation lists and the optimal parameters depending on their operating conditions. As you know, each CA periodically publishes lists of reviews, which include lists of all certificates that have been revoked by a specific CA. And each list includes all revoked certificates for the entire CA lifetime. With a CA's lifespan, for example, in 10 years, this list can grow to an impressive size (on the order of several megabytes).
Even with high-speed connections, revocation list traffic will be substantial in size, since all certificate consumers need the latest revocation list version.
To reduce the traffic of revocation lists, two types of CRLs are published: base (Base CRL) and differential (Delta CRL). The basic list includes a complete review list. The differential list includes only a list of revoked certificates that have been revoked since the last publication of the base CRL. This allows you to publish a basic list less frequently and for a longer period, and to speed up customer response times to revoked certificates, in the meantime, 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 withdrawal from downstream CAs is very low, as they are managed by trained personnel and are provided with appropriate security measures. Therefore, it can be argued that the volume of the revocation list may 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 amount of feedback? A typical empty CRL takes about 600-800 bytes. Each certificate revocation entry is 88 bytes. Based on these values, you can calculate the size of the CRL, depending on the number of revoked certificates.
It follows that throughout the lifetime of the root CA, the revocation list will be within 1kb and there is no point in the differential CRL.
Publishing CA
For the publishing CA, the picture changes. The volume of certificates issued is already high, it can be thousands and millions of pieces. Consumers are users and devices that are at high risk of revocation, since they are not under the constant supervision of qualified personnel, and it is impossible to provide adequate measures. As a result, the review list can reach serious sizes. For example, if you lay a 10% risk of revocation, then a million certificates issued account for about 100k revoked. 100k records of 88 bytes will be a little less than 10mb. It is not very practical to update the file on 10mb very often, it is more expedient to publish it less often, and to distribute several lightweight differential Delta CRLs between publications of the main CRL. Those. if only a basic revocation list is sufficient for a root CA, then deltas should be used for CAs issuing certificates to end users.
CRL scheduling validity
It was all about the composition of the revocation lists for each CA. Now we need to determine the dates:
- How long should a review list be published?
- How long the information in it can be considered reliable and quite relevant?
Here, too, you can apply the approach depending on the operating conditions. The risk of withdrawing an intermediate CA is very low, therefore, there is no point in publishing an empty CRL too often. In modern practice, the following typical values are applied for the CRL validity period for a CA, which issue certificates only to another CA: 3, 6 or 12 months. Here it is necessary to build on the degree of risk and administrative costs of maintaining the revocation 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 revocation of client certificates is high, one can assume a high revocation rate. Therefore, such CAs should publish revocation lists much more often, and to save traffic, combine basic and differential CRLs. By default, Microsoft CA publishes revocation lists with the following frequency: base 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, reducing one risk leads to an increase in another risk. Imagine that for some reason the CA server failed at a time when the previous CRL was about to expire, and the new CRL could not be published. Then problems will begin with checking certificate revocation and stopping them until the CA server is restored. This point must be taken into account when setting the validity of revocation lists.
Microsoft CA by default already lays some time reserve for emergencies and when distributing revocation lists to all publishing points takes some time (for example, caused by replication latency). This reserve in English terminology is called CRL overlap. The idea behind the defense mechanism is that the CA generates and publishes revocation lists before the previous published list expires.
This is achieved using two fields in the revocation list: Next CRL Publish and Next Update. The Next CRL Publish field indicates the time when the CA publishes the updated revocation list (automatically). Next Update indicates the time when the current list will expire. The Next Update field will always be set a little later than the Next CRL Publish. In other words, the CA will publish an updated revocation list before the previous one expires. The algorithm for calculating automatic values for these fields is non-trivial 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 is necessary to take into account that the time reserve has lower and upper bounds. For example, the upper bound cannot exceed the validity period of the CRL itself. So, if the CRL validity period is 1 day, then the stock can be a maximum of 1 day, and then the CA will publish revocation lists daily, but the validity period will be 2 days. Thereby, a time margin for restoring the CA in case of unforeseen circumstances is achieved.
In practice, I quite often observed the desire of administrators to tighten the CRL expiration settings to the minimum limit with the following rationale: “the user left and should not be able to authenticate with a revoked certificate”. The motivation is understandable, but solving the problem through revocation 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 the CRL validity and periodicity, the following guidelines should be followed:
- All CAs that issue certificates only to other CAs (not end users) must publish a CRL valid from 3 to 12 months with a one-month supply.
- All CAs that issue certificates to end users (users and devices) should 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
Within this series of articles, 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 article on TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide . As practice shows, in most cases, installation and support of OCSP is not justified for several reasons.
The main task of OCSP is to offload CRL download traffic. As you know, the CRL contains a list of all revoked certificates for the entire CA lifetime, and at some point with intensive revocation of certificates, its size can reach impressive sizes (several megabytes). As noted above, 100k revoked certificates will be about 9MB in the 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, the response rate is often much lower. If we talk about root CA or CA policy, they will have a piece of feedback, 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 verifiable certificate and many clients that want to verify it. This is a typical SSL / TLS certificate script. In this case, each client will spend 2.5KB of OCSP traffic instead of downloading a conditional 9MB revocation list. But in the opposite situation (one server verifies a lot of client certificates) OCSP can cause significant network load. This includes typical corporate network scenarios: client authentication using certificates, such as EAP-TLS authentication in wireless networks and VPN, Kerberos authentication on domain controllers. Suppose employees come to work and use certificates for network authentication (smart cards, certificates on mobile devices) and a domain controller, RADIUS servers are forced to verify each client certificate. To check only 1K certificates will be spent 2.5MB of traffic. 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 within a certain period of time, the Crypto API client checks 50 (this value can be configured) certificates from one publisher using OCSP, then this ends the work with OCSP and the client downloads and caches the CRL for that publisher. You can learn more about this behavior in the Optimizing the Revocation Experience section of the Certificate Revocation Checking in Windows Vista and Windows Server 2008 document.
Certificate issuance planning
Certificate issuance policies are one of the most difficult to understand aspects of certificate operation and are often completely ignored by administrators when planning and deploying PKI in an enterprise. However, the understanding and ability to manage issuance policies gives us a more flexible system, an additional level of control, and ultimately, a method of describing and documenting PKI.
Policy Definition
First you need to enter the definition of certificate issuance policies. Any process of issuing / receiving a certificate is essentially a contract between the certificate recipient and the issuing CA. This contract defines many aspects, such as issuance, use, and areas of responsibility.
Each company may have different methods for checking applications and issuing certificates. Consider a few typical cases:
- Certificates for signing email can be issued automatically with minimal verification of the applicant (only on the basis of successful user authentication in Active Directory). No additional steps are taken to issue these certificates.
- Certificates for digital signature of documents can be issued only after agreement with the immediate supervisor and submission 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 briefing on the rules for using the cards, signing the relevant regulatory documents.
- , , -.
. , . , — .. , , (, ).
, . . Network Policy Server (NPS) Active Directory Dynamic Access Control . , . , -.
NPS , , , -. , NPS ( ) . , , . Active Directory Dynamic Access Control, .
, . , , . , ? .
, - . , . , . . , ( PKI ) , , , .
: PKI – Certificate Practice Statement CPS ( , , ). ( ) , RFC 3647 . , PKI. . , , - .
CPS :
- PKI, , .
- . PKI, , CPS, , .
CPS ( ). CPS ( ).
ITU-T ISO. : OID' ? , IANA (Internet Assigned Numbers Authority) . , , : 1.3.6.1.4.1.x.1, x – , IANA. :
- 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
- ...
, . , , . Certificate Policies , .
, DigiCert, 2.16.840.1.114412.2.1 ( Extended Validation ) 2.23.140.1.1 (, CAB/Forum) CPS. CPS .
, , , . . , - , , ( ). : Certificate Policies extension – all you should know (part 1) Certificate Policies extension – all you should know (part 2) . , , Windows.
: (10 ) , . (, ), . RFC 5280 §4.2.1.4 (global wildcard) anyPolicy = 2.5.29.32.0, .
, , . , .. , , , , anyPolicy , . , . anyPolicy .
AD CS ( ). (, ). , (AD CS JET Database Engine). This is in theory.
, . Windows Server 2003 Evaluating CA Capacity, Performance, and Scalability ( , .. TechNet), , . (, ), .
2010 , Windows PKI Team ( 2007 ) Windows Server 2008. : Windows CA Performance Numbers . , , AD CS 2007 150 . . . , . Windows Server 2016 ( Windows Server 2016 System Requirements ):
- CPU — dual-core 1.4 GHz;
- — 1GB RAM;
- — 48 GB 48 GB . RAID1.
- — SVGA (800*600);
- — .
, ( ) ( ) .
( ), . , , . .
.
| Standalone CA | |
| Root CA | |
| 15 | |
| AD () | Certification Authorities AIA |
| CRT | 1) - 2) C:\CertData\contoso-rca<CertificateName>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CertificateName>.crt* |
| CRT | 1) URL=http://cdp.contoso.com/pki/contoso-rca<CertificateName>.crt |
| CRL | 1) - 2) C:\CertData\contoso-rca<CRLNameSuffix>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CRLNameSuffix>.crt* |
| CRL | 1) URL=http://cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt |
| Contoso Lab Root Certification authority | |
| OU=Division Of IT, O=Contoso Pharmaceuticals, C=US | |
| RSA#Microsoft Software Key Storage Provider | |
| 4096 | |
| SHA256 | |
| Validity | 15 |
| CRL | Base CRL |
| Base CRL | |
| Type of | Base CRL |
| Validity | 6 months |
| 1 month | |
| SHA256 | |
| AD | Not |
.
| Enterprise CA | |
| Subordinate CA | |
| : 5 ( ) | |
| Not | |
| AD () | AIA NTAuthCertificates |
| CRL | Base CRL Delta CRL |
| CRT | 1) - 2) \\IIS\PKI\contoso-pica<CertificateName>.crt |
| CRT | 1) URL=http://cdp.contoso.com/pki/contoso-pica<CertificateName>.crt |
| CRL | 1) - 2) \\IIS\PKI\contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl |
| CRL | 1) URL=http://cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl |
| Contoso Lab Issuing Certification authority | |
| OU=Division Of IT, O=Contoso Pharmaceuticals, C=US | |
| RSA#Microsoft Software Key Storage Provider | |
| 4096 | |
| SHA256 | |
| Validity | 15 ( ) |
| 1) : All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html | |
| Basic Constraints | isCA=True ( — ) PathLength=0 ( ). |
| Base CRL | |
| Type of | Base CRL |
| Validity | Week 1 |
| Default | |
| SHA256 | |
| AD | Not |
| Delta CRL | |
| Type of | Delta CRL |
| Validity | 1 day |
| - | |
| SHA256 | |
| AD | Not |
IIS
| - | cdp |
| cdp.contoso.com | |
| PKI=C:\InetPub\wwwroot\PKIdata | |
| Double Escaping | |
, . , .
about the author
— PowerShell Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management 2009 PowerShell PKI. 9 PKI . PKI PowerShell .Source: https://habr.com/ru/post/348956/
All Articles