An internal PKI Infrastructure in my mind is a must to secure internal communications as you would external communications. When people think about certificates (and they often do not) they think SSL (secure socket layers) delivery of web content. What they do not think about with certificates are things like client/server authentication, user domain access, securing Wi-Fi access with PKI, direct access, securing system center products (configurations manager, operations manager, data protection manager, service manager, orchestrator, virtual machine manager) and many more. What about securing internal communications within the DMZ (demilitarized zone)? Perhaps utilizing the hybrid secure functionality of Windows Server Update Services?
Note: A private CA is highly unlikely to be trusted outside the network environment.
In my mind we should secure everything, yes that does come with a price. The price tag is knowledge, comprehension, understanding, training, and attentiveness. You will also want to introduce certificate lifecycle management (so things do not get out of hand nor forgotten, “attentiveness”). A forgotten root certificate that expires is annoying, and at the same time if your root certificate is expired then I guarantee you that all of your certificate authority certificates have expired.
(Believe me you will notice if this happens)
When you are first installing an internal PKI infrastructure the basic concept is quite simple. A three server minimum (offers no high availability with only three member servers).
- Server 1
- Offline root certificate authority
- Server 2
- Offline policy server
- Also known as an intermediate certificate authority.
- Server 3
- Certificate issuing authority
- Two or more of these is a wise
- Round robin DNS and a little creativity with CRL and CRT storage locations will create a highly available certificate issuing authority.
This is known as a three-tier model,
yes a two-tier model is an option if you do not wish to harness the
possibilities with PKI policies.
If you are like myself, a gluten for punishment then may I direct your attention here
RFC (request for comment) 3647 . Whenever I truly want to understand the foundation of a technology there is no better place to start than with the “Request for Comment” that was originally submitted about the technology, which ultimately defines the framework of said technology.
Excerpt: from The Internet Engineering Task Force (IETF®) https://www.ietf.org
3.1. Certificate Policy
When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
The X.509 standard defines a CP as “a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements” [ISO1]. An X.509 Version 3 certificate may identify a specific applicable CP, which may be used by a relying party to decide whether or not to trust a certificate, associated public key, or any digital signatures verified using the public key for a particular purpose.
CPs typically fall into two major categories. First, some CPs “indicate the applicability of a certificate to a particular community” [ISO1]. These CPs set forth requirements for certificate usage and requirements on members of a community. For instance, a CP may focus on the needs of a geographical community, such as the ETSI policy requirements for CAs issuing qualified certificates [ETS]. Also, a CP of this kind may focus on the needs of a specific vertical-market community, such as financial services [IDT].
The second category of typical CPs “indicate the applicability of a certificate to a . . . class of application with common security requirements.” These CPs identify a set of applications or uses for certificates and say that these applications or uses require a certain level of security. They then set forth PKI requirements that are appropriate for these applications or uses. A CP within this category often makes sets requirements appropriate for a certain “level of assurance” provided by certificates, relative to certificates issued pursuant to related CPs. These levels of assurance may correspond to “classes” or “types” of certificates.
For instance, the Government of Canada PKI Policy Management Authority (GOC PMA) has established eight certificate policies in a single document [GOC], four policies for certificates used for digital signatures and four policies for certificates used for confidentiality encryption. For each of these applications, the document establishes four levels of assurances: rudimentary, basic, medium, and high. The GOC PMA described certain types of digital signature and confidentiality uses in the document, each with a certain set of security requirements, and grouped them into eight categories. The GOC PMA then established PKI requirements for each of these categories, thereby creating eight types of certificates, each providing rudimentary, basic, medium, or high levels of assurance. The progression from rudimentary to high levels corresponds to increasing security requirements and corresponding increasing levels of assurance.
A CP is represented in a certificate by a unique number called an “Object Identifier” (OID). That OID, or at least an “arc”, can be registered. An “arc” is the beginning of the numerical sequence of an OID and is assigned to a particular organization. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID or arc also can publish the text of the CP, for examination by relying parties. Any one certificate will typically declare a single CP or, possibly, be issued consistent with a small number of different policies. Such declaration appears in the Certificate Policies extension of a X.509 Version 3 certificate. When a CA places multiple CPs within a certificate’s Certificate Policies extension, the CA is asserting that the certificate is appropriate for use in accordance with any of the listed CPs.
CPs also constitute a basis for an audit, accreditation, or another assessment of a CA. Each CA can be assessed against one or more certificate policies or CPSs that it is recognized as implementing. When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon an assessment with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these CP indications in its well-defined trust model.
If reading or understanding this does not bore you to tears or leave you shaking with fear then, you my friend have chosen the right career.