Installation of a certification authority in the enterprise. Part 1
Hi, Habr! We are starting a new series of articles. It will focus on deploying certificate services in a Windows Server 2016-based enterprise with practical examples. Today we mark the introductory moments and talk about typical deployment schemes for the PKI hierarchy: two-level and multi-level. Read all about it under the cut.
IT administrators, IT engineers, and security professionals with basic digital certificate concepts.
The following abbreviations and abbreviations have been used in this part of the series:
Encryption, digital signatures and certificates are entering our everyday Internet life more and more closely. 10 years ago, little was said about these terms, and not all IT specialists knew the meaning of these words, but now they are widely known. And this process does not last a year or two, but a good ten years. Now we are in the active phase of the development of client-server web services (hello to mainframes!), And a large proportion of the communication of people and devices is shifted to computer networks and the Internet. As a result, new conditions dictate new data protection requirements. Large software vendors are actively promoting the ideology of "secure Internet", demanding the support of digital certificates, ranging from servers with confidential data, cloud services, right up to the kitchen kettle or linen iron (IoT).
Some companies do this very aggressively. So, starting in 2017, Google considers all sites without HTTPS support unsafe: Moving towards a more secure web . And it has a very significant effect on the Internet industry. Firstly, the warning in the browser (Google Chrome) clearly will not please your potential customers and just visitors. Secondly, sites without HTTPS support are omitted from the search results. Mozilla and other large vendors also keep up with Google: Deprecating Non-Secure HTTP . On the one hand, companies are putting pressure on the Internet industry, pushing organizations to the additional costs associated with digital certificates. On the other hand, this is a forced step, and everyone needs to keep up with the times.
However, the current position of the Internet PKI does not allow to solve these issues quite flexibly and conveniently, requiring substantial costs. For example, one SSL certificate for a public web server will cost you about $ 100, and if you want a certificate with a green bar, it will cost you even more. And this is only for one certificate! At the same time, process automation is in the most rudimentary state.
To solve these problems, the largest software vendors have teamed up and jointly put things in order with digital certificates on the Internet PKI. First, a single standardizing body, the CAB Forum (CA / Browser Forum), was established, which defines standard practices for commercial CAs, web software producers, and consumers of certificates. Secondly, the active promotion of non-commercial CA (but globally trusted) Let's Encrypt to provide free certificates with the possibility of automatic renewal.
It would seem that this solves all the problems of secure communication, and private PKIs (deployed within the organization) immediately become unnecessary. In some, yes, if a private PKI was engaged in servicing external servers (web, VPN, etc.). But services like Let's Encrypt currently cover only a narrow range of corporate certificate requirements. For example, certificates for encrypting documents, mail, digital signatures are not covered. Part of the task, as client authentication is not covered at all. Another limitation is that in order to use public certificates issued by commercial CAs you need to have a public domain. It’s technically impossible to get a certificate for a web server addressed to domain.local from Let's Encrypt. That is why the relevance of private PKI remains at a very high level. An example of using private PKIs in a corporate environment is shown in the following figure:
If a company decides to use a private PKI within the organization, another urgent question arises: how to organize it properly, so that it meets modern practices and standards, at least within the organization. On the Internet you can find numerous articles on how to deploy PKI in a company based on Active Directory Certificate Services (ADCS). But for the most part they are full of errors, come from wrong premises and are often copying some kind of source (not always successful) material, and add their own to the existing fundamental mistakes. As a result, numerous failures in the deployment of PKI. This can be judged by the number of relevant topics on the forums (in particular, TechNet Server Security ). There is a lack of quality documentation in English, and in Russian ... This cycle of articles is intended to fill this gap and systematize modern developments.
PKI is a security technology that is based on the X.509 standard and uses digital certificates. The purpose of PKI is to increase the security of the IT infrastructure of an enterprise by providing mechanisms to protect data from unauthorized access and illegal data changes (data falsification). This is achieved by two main cryptographic mechanisms:
A typical PKI infrastructure consists of the following components:
The structure of the CA and certificates are arranged in a tree hierarchy. Each CA can perform one or more (combine) roles:
To understand the process of building certificate chains, I recommend reading the following article: Certificate Chaining Engine - how it works . This article focuses on the Microsoft CryptoAPI platform; it is also valid (with some exceptions) for other implementations of cryptographic platforms.
Since CAs are arranged in a tree-like hierarchy, it is possible to organize a multi-level hierarchy, where at each level the CA will perform both the role of a publishing CA and additional functions. In the simplest case, a single CA can combine all the roles, i.e. be root, provide some kind of issuance policy and issue certificates to end users. Larger companies and / or with a more mature organization of IT processes already use the separation of the CA by roles. For example, in the head office they keep the root CA, issuing certificates only to other CA, which already imposes issuance policies on themselves. They may not directly serve end-users, but issue certificates to other subordinate CAs, which, in turn, will serve end-users. Each approach has its pros and cons, which will be discussed below.
In addition to issuing certificates, each CA periodically releases revocation lists (Certificate Revocation List, CRL). Like certificates, the integrity of revocation lists is digitally signed. The CRL contains the serial numbers of certificates that are terminated for any reason before the official expiration of the certificate. Thus, the CA ensures the timely withdrawal of an invalid certificate from circulation.
Each client, after installing a trust certificate through a chain, must ensure that no certificate in the chain has been revoked by its publisher. To do this, the client enumerates each certificate in the chain, selects the CRL provided by the publisher, and checks the presence / absence of the current certificate in the CRL. If the current certificate is in the CRL, then the trust in the certificate (and all branches of the tree below it) is automatically terminated.
In fact, if the root CA has revoked all of its directly issued certificates, then no certificate under this root will be trusted, regardless of the height of the hierarchy. One very important and fundamental point should be noted here: it is impossible to revoke a root (self-signed) certificate . Those. if for some reason it has been compromised, it can be revoked only by forcibly deleting the certificate from the certificate store of each client. The fact is that the CA does not define lists of reviews for itself; the publisher does this. In the case of a self-signed certificate, the CA is the publisher of itself. And when you try to include yourself in your own revocation list, you get uncertainty: the CA certificate is included in the CRL, which is signed by the key of the same CA. Assuming that the CA certificate is invalid, then the digital signature on the CRL is invalid. As a result, it is impossible to reliably state that the root CA certificate has been revoked. Moreover, the revocation of root certificates is not provided for and the main regulatory standard, RFC 5280 , paragraph §6.1 of which reads as follows:
And only the prospective chain is checked for feedback. If we talk in the context of Microsoft ADCS, then the situation is aggravated even more. In particular, you can technically revoke a root certificate with certutil.exe or CryptoAPI. But as soon as you do this, the CA will not be able to sign any CRL, as a result, the CA certificate will never be included in the CRL. Moreover, even if you use different utilities (the same certutil.exe), you can forcibly include the CA certificate in the CRL, but this is of little help. The fact is that the default configuration of CryptoAPI does not even attempt to check the root certificate for revocation.
The problem of revoking root certificates in many cases will be one of the decisive factors in choosing the appropriate CA hierarchy for a company. It will also dictate additional security measures for root CAs in order to minimize the risk of compromise of the root CA.
In this section, we will look at typical (or classic) deployment schemes of the PKI hierarchy in an enterprise environment and evaluate each schema and recommendations. It should be noted that none of them is universal, and each can make sense within its own limits.
The single-level hierarchy is the simplest to implement and has the following form:
Such a hierarchy is the easiest and most economical both in terms of resources (licenses) and maintenance and management costs. It is enough to deploy one such CA in an Active Directory forest, and it will provide certificates for all consumers. Of the unobvious, but important advantages can be noted a very short chain of certificates. Those. time to check the power of attorney and certificate revocation will be spent much less than in any other hierarchy.
However, the single-level hierarchy has a number of rather significant drawbacks. The largest of them is a low level of security. Since the CA in such a scheme must be permanently connected to the network so that customers can request certificates, the risk of its compromise increases significantly. The consequences of compromising can be monstrous, even to the complete loss of control over Active Directory and the collapse of IT systems. This may be caused by insufficient security measures, the presence of non-closed OS vulnerabilities or system components that allow remote code execution, etc. As noted above, it is no longer possible to revoke such a certificate in the normal way, and the consequences will be really grave.
Another point is related to the flexibility of splitting the CA into functional levels (delegation). For example, it is impossible to organize several different issuance policies, divide them into classes (for example, one CA issues certificates only to machines and devices, the other only to users), etc., because it is only one.
The disadvantages of a single-level hierarchy significantly outweigh its advantages in lightness and compactness. That is why this configuration makes sense only in some small and isolated networks with low security requirements. For example, it may be some kind of test environment. In a business environment, this solution is not recommended.
A two-level hierarchy already implies at least two CAs in a tree, in which one is strictly root and the others are subordinate. The scheme of such a hierarchy is presented below:
Note: here the dotted lines mark the manual (non-automated) process of obtaining a certificate. Solid lines marked the automated process of obtaining certificates.
In a two-level hierarchy, it is already possible to solve the disadvantages of a single-level hierarchy. Here, the root CA issues certificates only for subordinate CAs, and already a subordinate CA issues certificates to end users. Since publishing CAs are deployed less frequently, and their validity is long enough, this allows you to isolate the root CA from the network. This automatically nullifies the chance of such a CA being compromised, since you cannot reach it without a network. Moreover, it can (and should) spend the main lifetime in the off state. You only need to enable it to update your own certificate, subordinate CA or to publish a new CRL. The rest of the time no one needs it.
Another advantage of the two-level hierarchy is the improved flexibility in splitting subordinate CAs into some classes. The same typical scenario, when two CAs are managed by different IT departments, and each CA issues certificates for its consumer groups. For example, for machines separately, for users separately. It is possible for corporate developers (who usually live in their own environments) to single out their subordinate CA.
It is here that one can begin to think about the separation of the CA by issuing policies (or classes). For example, you can allocate one CA for issuing certificates with increased certificate requirements (for example, certificates for authentication and digital signatures) and a general CA. They can be managed by various teams of IT administrators. In addition, each subordinate CA will combine the tasks of the CA policy and the issuing CA. This is perfectly acceptable if we assume that the number of CAs for each class is not more than one.
Among the shortcomings, there is only a slight increase in both administrative and financial costs (an additional license is required). To the administrative costs will be added control over the validity of each CA and the revocation list of the root CA, as well as their timely update. In addition, the time to build and verify certificate chains will increase slightly, as another level is added. In practice, this time is practically not noticeable.
For small and medium-sized enterprises, such a scheme is the most optimal, since it allows to ensure an adequate level of security and an acceptable level of flexibility in dividing the CA into certain functions.
In larger companies with complex networking, it may happen that a two-tier hierarchy cannot provide the necessary level of flexibility in CA management. For example, when a company uses the geographical principle of separation with relative autonomy of IT departments in each region. Imagine an international company with regional offices in different countries. They may have their own legislation on security issues, for example, in the processing of personal data. To comply with such legal formalities, each such region is allocated its own CA policy (at the same time, it is usually located at the head office of the company). In his certificate, he indicates support (and a link to the relevant document) of various regulatory documents and issues certificates for issuing CAs operating under those policies that are indicated in the certificate (roughly speaking, in a given region).
In such hierarchies, the root CA and CA of the politician are isolated from the network, and only the publishing CA is already connected to the network:
There is also a dotted line marked by the manual process of obtaining a certificate for the CA and full lines automated process of obtaining a certificate for customers.
The advantages of this scheme include the flexibility of the resulting PKI with the ability to adapt to almost any conditions. True, you have to pay for it. First, multi-level hierarchies increase the cost of deploying and maintaining PKI. Secondly, clients need more time to build and check for revocation of complete certificate chains, which can cause failures due to exceeding the timeouts of the upper data transfer protocols. And in practice, such schemes are often redundant. Therefore, when choosing a suitable CA hierarchy, a balance should be found between flexibility and practical feasibility, taking into account the capital and operating costs of maintaining a PKI.
In this series of articles, the most popular (in most cases) two-level hierarchy is considered.
Vadim Podans is a specialist in automation of PowerShell and Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management since 2009 and the author of the PowerShell module PKI. For 9 years, she has been covering various issues of operation and automation of PKI in an enterprise in her blog. Vadim's articles on PKI and PowerShell can be found on his website .
The second part of the series
')
Third part of the series
Introduction
The target audience
IT administrators, IT engineers, and security professionals with basic digital certificate concepts.
Glossary
The following abbreviations and abbreviations have been used in this part of the series:
- PKI ( Public Key Infrastructure ) - a public key infrastructure ( PKI ), 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.
- SSL ( Secure Sockets Layer ) or TLS ( Transport Layer Security ) is a technology that ensures the security of data transmission between the client and the server over open networks.
- HTTPS ( HTTP / Secure ) - secure HTTP, which 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.
Why do you need a private PKI?
Encryption, digital signatures and certificates are entering our everyday Internet life more and more closely. 10 years ago, little was said about these terms, and not all IT specialists knew the meaning of these words, but now they are widely known. And this process does not last a year or two, but a good ten years. Now we are in the active phase of the development of client-server web services (hello to mainframes!), And a large proportion of the communication of people and devices is shifted to computer networks and the Internet. As a result, new conditions dictate new data protection requirements. Large software vendors are actively promoting the ideology of "secure Internet", demanding the support of digital certificates, ranging from servers with confidential data, cloud services, right up to the kitchen kettle or linen iron (IoT).
Some companies do this very aggressively. So, starting in 2017, Google considers all sites without HTTPS support unsafe: Moving towards a more secure web . And it has a very significant effect on the Internet industry. Firstly, the warning in the browser (Google Chrome) clearly will not please your potential customers and just visitors. Secondly, sites without HTTPS support are omitted from the search results. Mozilla and other large vendors also keep up with Google: Deprecating Non-Secure HTTP . On the one hand, companies are putting pressure on the Internet industry, pushing organizations to the additional costs associated with digital certificates. On the other hand, this is a forced step, and everyone needs to keep up with the times.
However, the current position of the Internet PKI does not allow to solve these issues quite flexibly and conveniently, requiring substantial costs. For example, one SSL certificate for a public web server will cost you about $ 100, and if you want a certificate with a green bar, it will cost you even more. And this is only for one certificate! At the same time, process automation is in the most rudimentary state.
To solve these problems, the largest software vendors have teamed up and jointly put things in order with digital certificates on the Internet PKI. First, a single standardizing body, the CAB Forum (CA / Browser Forum), was established, which defines standard practices for commercial CAs, web software producers, and consumers of certificates. Secondly, the active promotion of non-commercial CA (but globally trusted) Let's Encrypt to provide free certificates with the possibility of automatic renewal.
It would seem that this solves all the problems of secure communication, and private PKIs (deployed within the organization) immediately become unnecessary. In some, yes, if a private PKI was engaged in servicing external servers (web, VPN, etc.). But services like Let's Encrypt currently cover only a narrow range of corporate certificate requirements. For example, certificates for encrypting documents, mail, digital signatures are not covered. Part of the task, as client authentication is not covered at all. Another limitation is that in order to use public certificates issued by commercial CAs you need to have a public domain. It’s technically impossible to get a certificate for a web server addressed to domain.local from Let's Encrypt. That is why the relevance of private PKI remains at a very high level. An example of using private PKIs in a corporate environment is shown in the following figure:
If a company decides to use a private PKI within the organization, another urgent question arises: how to organize it properly, so that it meets modern practices and standards, at least within the organization. On the Internet you can find numerous articles on how to deploy PKI in a company based on Active Directory Certificate Services (ADCS). But for the most part they are full of errors, come from wrong premises and are often copying some kind of source (not always successful) material, and add their own to the existing fundamental mistakes. As a result, numerous failures in the deployment of PKI. This can be judged by the number of relevant topics on the forums (in particular, TechNet Server Security ). There is a lack of quality documentation in English, and in Russian ... This cycle of articles is intended to fill this gap and systematize modern developments.
General provisions
PKI is a security technology that is based on the X.509 standard and uses digital certificates. The purpose of PKI is to increase the security of the IT infrastructure of an enterprise by providing mechanisms to protect data from unauthorized access and illegal data changes (data falsification). This is achieved by two main cryptographic mechanisms:
- Encryption - protects data from unauthorized access by third parties by encrypting data with cryptographic keys. Only users with the necessary keys can access the data. Encryption ensures data privacy, but does not protect against their substitution.
- Digital signature - protects data from unauthorized changes or tampering by applying special algorithms to the data that form a digital signature. Any manipulations to change the data will be immediately detected during the verification of the digital signature. Digital signature does not ensure the confidentiality of data, but their integrity. By combining encryption and digital signatures, you can organize privacy and protect data from unauthorized changes.
A typical PKI infrastructure consists of the following components:
- A Certification Authority (CA) is a service that provides digital certificates to consumers and provides PKI functionality.
- A revocation server is a service that provides information about the lists of revoked (compromised or invalid) certificates issued by a specific CA.
- The client is a recipient of a certified digital certificate from a certification authority. Clients can be people, devices, software, and other CAs.
The structure of the CA and certificates are arranged in a tree hierarchy. Each CA can perform one or more (combine) roles:
- The root CA is a special type of CA that has a self-signed certificate and is the root of the tree (hence the name). This type of CA is the starting point of trusting all certificates in a given hierarchy (tree). In other words, the client must explicitly trust a particular root certificate (namely, the combination: publisher and public key) in order to trust certificates located in the rest of the tree. It is important to note that trust is transitive. When checking the final certificate, the client will build a chain (path) from the final certificate to the top of the hierarchy (root certificate). And if the client trusts the top, then there will be reason to trust the final certificate as transitive.
- The CA is a politician - technically, it is the same CA as everyone else (in terms of the hierarchy), with the difference that is complemented by foreign policies and restrictions on issuing and using digital certificates.
- The issuing CA is a general-purpose CA that signs and issues digital certificates to consumers.
To understand the process of building certificate chains, I recommend reading the following article: Certificate Chaining Engine - how it works . This article focuses on the Microsoft CryptoAPI platform; it is also valid (with some exceptions) for other implementations of cryptographic platforms.
Since CAs are arranged in a tree-like hierarchy, it is possible to organize a multi-level hierarchy, where at each level the CA will perform both the role of a publishing CA and additional functions. In the simplest case, a single CA can combine all the roles, i.e. be root, provide some kind of issuance policy and issue certificates to end users. Larger companies and / or with a more mature organization of IT processes already use the separation of the CA by roles. For example, in the head office they keep the root CA, issuing certificates only to other CA, which already imposes issuance policies on themselves. They may not directly serve end-users, but issue certificates to other subordinate CAs, which, in turn, will serve end-users. Each approach has its pros and cons, which will be discussed below.
Certificate revocation
In addition to issuing certificates, each CA periodically releases revocation lists (Certificate Revocation List, CRL). Like certificates, the integrity of revocation lists is digitally signed. The CRL contains the serial numbers of certificates that are terminated for any reason before the official expiration of the certificate. Thus, the CA ensures the timely withdrawal of an invalid certificate from circulation.
Each client, after installing a trust certificate through a chain, must ensure that no certificate in the chain has been revoked by its publisher. To do this, the client enumerates each certificate in the chain, selects the CRL provided by the publisher, and checks the presence / absence of the current certificate in the CRL. If the current certificate is in the CRL, then the trust in the certificate (and all branches of the tree below it) is automatically terminated.
In fact, if the root CA has revoked all of its directly issued certificates, then no certificate under this root will be trusted, regardless of the height of the hierarchy. One very important and fundamental point should be noted here: it is impossible to revoke a root (self-signed) certificate . Those. if for some reason it has been compromised, it can be revoked only by forcibly deleting the certificate from the certificate store of each client. The fact is that the CA does not define lists of reviews for itself; the publisher does this. In the case of a self-signed certificate, the CA is the publisher of itself. And when you try to include yourself in your own revocation list, you get uncertainty: the CA certificate is included in the CRL, which is signed by the key of the same CA. Assuming that the CA certificate is invalid, then the digital signature on the CRL is invalid. As a result, it is impossible to reliably state that the root CA certificate has been revoked. Moreover, the revocation of root certificates is not provided for and the main regulatory standard, RFC 5280 , paragraph §6.1 of which reads as follows:
It is not included in the form of a certificate.
And only the prospective chain is checked for feedback. If we talk in the context of Microsoft ADCS, then the situation is aggravated even more. In particular, you can technically revoke a root certificate with certutil.exe or CryptoAPI. But as soon as you do this, the CA will not be able to sign any CRL, as a result, the CA certificate will never be included in the CRL. Moreover, even if you use different utilities (the same certutil.exe), you can forcibly include the CA certificate in the CRL, but this is of little help. The fact is that the default configuration of CryptoAPI does not even attempt to check the root certificate for revocation.
The problem of revoking root certificates in many cases will be one of the decisive factors in choosing the appropriate CA hierarchy for a company. It will also dictate additional security measures for root CAs in order to minimize the risk of compromise of the root CA.
Typical PKI hierarchy deployment schemes
In this section, we will look at typical (or classic) deployment schemes of the PKI hierarchy in an enterprise environment and evaluate each schema and recommendations. It should be noted that none of them is universal, and each can make sense within its own limits.
Single-level hierarchy
The single-level hierarchy is the simplest to implement and has the following form:
Such a hierarchy is the easiest and most economical both in terms of resources (licenses) and maintenance and management costs. It is enough to deploy one such CA in an Active Directory forest, and it will provide certificates for all consumers. Of the unobvious, but important advantages can be noted a very short chain of certificates. Those. time to check the power of attorney and certificate revocation will be spent much less than in any other hierarchy.
However, the single-level hierarchy has a number of rather significant drawbacks. The largest of them is a low level of security. Since the CA in such a scheme must be permanently connected to the network so that customers can request certificates, the risk of its compromise increases significantly. The consequences of compromising can be monstrous, even to the complete loss of control over Active Directory and the collapse of IT systems. This may be caused by insufficient security measures, the presence of non-closed OS vulnerabilities or system components that allow remote code execution, etc. As noted above, it is no longer possible to revoke such a certificate in the normal way, and the consequences will be really grave.
Another point is related to the flexibility of splitting the CA into functional levels (delegation). For example, it is impossible to organize several different issuance policies, divide them into classes (for example, one CA issues certificates only to machines and devices, the other only to users), etc., because it is only one.
The disadvantages of a single-level hierarchy significantly outweigh its advantages in lightness and compactness. That is why this configuration makes sense only in some small and isolated networks with low security requirements. For example, it may be some kind of test environment. In a business environment, this solution is not recommended.
Two-level hierarchy
A two-level hierarchy already implies at least two CAs in a tree, in which one is strictly root and the others are subordinate. The scheme of such a hierarchy is presented below:
Note: here the dotted lines mark the manual (non-automated) process of obtaining a certificate. Solid lines marked the automated process of obtaining certificates.
In a two-level hierarchy, it is already possible to solve the disadvantages of a single-level hierarchy. Here, the root CA issues certificates only for subordinate CAs, and already a subordinate CA issues certificates to end users. Since publishing CAs are deployed less frequently, and their validity is long enough, this allows you to isolate the root CA from the network. This automatically nullifies the chance of such a CA being compromised, since you cannot reach it without a network. Moreover, it can (and should) spend the main lifetime in the off state. You only need to enable it to update your own certificate, subordinate CA or to publish a new CRL. The rest of the time no one needs it.
Another advantage of the two-level hierarchy is the improved flexibility in splitting subordinate CAs into some classes. The same typical scenario, when two CAs are managed by different IT departments, and each CA issues certificates for its consumer groups. For example, for machines separately, for users separately. It is possible for corporate developers (who usually live in their own environments) to single out their subordinate CA.
It is here that one can begin to think about the separation of the CA by issuing policies (or classes). For example, you can allocate one CA for issuing certificates with increased certificate requirements (for example, certificates for authentication and digital signatures) and a general CA. They can be managed by various teams of IT administrators. In addition, each subordinate CA will combine the tasks of the CA policy and the issuing CA. This is perfectly acceptable if we assume that the number of CAs for each class is not more than one.
Among the shortcomings, there is only a slight increase in both administrative and financial costs (an additional license is required). To the administrative costs will be added control over the validity of each CA and the revocation list of the root CA, as well as their timely update. In addition, the time to build and verify certificate chains will increase slightly, as another level is added. In practice, this time is practically not noticeable.
For small and medium-sized enterprises, such a scheme is the most optimal, since it allows to ensure an adequate level of security and an acceptable level of flexibility in dividing the CA into certain functions.
Three or more hierarchies
In larger companies with complex networking, it may happen that a two-tier hierarchy cannot provide the necessary level of flexibility in CA management. For example, when a company uses the geographical principle of separation with relative autonomy of IT departments in each region. Imagine an international company with regional offices in different countries. They may have their own legislation on security issues, for example, in the processing of personal data. To comply with such legal formalities, each such region is allocated its own CA policy (at the same time, it is usually located at the head office of the company). In his certificate, he indicates support (and a link to the relevant document) of various regulatory documents and issues certificates for issuing CAs operating under those policies that are indicated in the certificate (roughly speaking, in a given region).
In such hierarchies, the root CA and CA of the politician are isolated from the network, and only the publishing CA is already connected to the network:
There is also a dotted line marked by the manual process of obtaining a certificate for the CA and full lines automated process of obtaining a certificate for customers.
The advantages of this scheme include the flexibility of the resulting PKI with the ability to adapt to almost any conditions. True, you have to pay for it. First, multi-level hierarchies increase the cost of deploying and maintaining PKI. Secondly, clients need more time to build and check for revocation of complete certificate chains, which can cause failures due to exceeding the timeouts of the upper data transfer protocols. And in practice, such schemes are often redundant. Therefore, when choosing a suitable CA hierarchy, a balance should be found between flexibility and practical feasibility, taking into account the capital and operating costs of maintaining a PKI.
In this series of articles, the most popular (in most cases) two-level hierarchy is considered.
about the author
Vadim Podans is a specialist in automation of PowerShell and Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management since 2009 and the author of the PowerShell module PKI. For 9 years, she has been covering various issues of operation and automation of PKI in an enterprise in her blog. Vadim's articles on PKI and PowerShell can be found on his website .Source: https://habr.com/ru/post/348944/
All Articles