2

I want to save on OS license, simplify CRL renewals and have more than one certificate instance on a given server.

For me, this makes sense from a security perspective because I have:

  • One CA that acts as the root, that needs to publish & renew CRLs for policy servers (next bullet point)

  • There are many, many Policy servers (2nd tier) that are constrained by Name Constraints or EKU usages. Likewise these too need to publish many CRLs and AIA records.

  • We currently estimate a need of 10,000 to 50,000 policy servers. Each policy server will have a CRL stored in Azure blob storage, with a dedicated container for each server for IO scalability.

Based on the output of certutil -ping (namely the config parameter) it appears that I can have more than one configuration per ADCS instance.

In addition, several other parameters of Certutil (and the corresponding API) allow me to specify which "instance" I want to connect to.

/// --- NOTE: The ability to specify an individual config seems to indicate multiple PKIs are possible per box:
PS C:\Windows\system32\CertSrv\en-US> certutil -ping -config "a.Issue01.bitclear.us\Secure Issuer 01a-001"
Connecting to a.Issue01.bitclear.us\Secure Issuer 01a-001 ...
Server "Secure Issuer 01a-001" ICertRequest2 interface is alive (0ms)
CertUtil: -ping command completed successfully.

 /// --- NOTE "Entry 0" implies that more entries are possible
PS C:\Windows\system32\CertSrv\en-US> certutil -v
Entry 0: (Local)
  Name:                         `Secure Issuer 01a-001'
  Organizational Unit:          `Email Privacy'
  Organization:                 `Bitclear LLC'
  Locality:                     `'
  State:                        `'
  Country/region:               `us'
  Config:                       `a.Issue01.bitclear.us\Secure Issuer 01a-001'
  Exchange Certificate:         `'
  Signature Certificate:        `a.Issue01.bitclear.us_Secure Issuer 01a-001.crt'
  Description:                  `'
  Server:                       `a.Issue01.bitclear.us'
  Authority:                    `Secure Issuer 01a-001'
  Sanitized Name:               `Secure Issuer 01a-001'
  Short Name:                   `Secure Issuer 01a-001'
  Sanitized Short Name:         `Secure Issuer 01a-001'
  Flags:                        `13'
  Web Enrollment Servers:
1
4
0
https://a.issue01.bitclear.us/Secure%20Issuer%2001a-001_CES_UsernamePassword/service.svc/CES
0
CertUtil: -dump command completed successfully.

Is it possible to host more than one PKI per ADCS host? How would this be done?

Aside: I remember there being discussion this might be possible in the past, but I'm not sure if it was implemented.

Todo:

I will test this theory with a custom CertFile and a New name when I run the command:

certutil -installcert [-f] [-gmt] [-seconds] [-v] [-config CAMachineName\CAName] [CACertFile]

It's possible that this is also somehow related to "PolicyServers" and "EnrollmentServers" that can be connected with this command. The ability to separate these from the core ADCS instance is very interesting, and note really documented.

2 Answers 2

1

My understanding is that you can only have one ADCS instance per host and up to 3 CAs in the AD Forest. The "\CA Name" is more about the name of your PKI Tree and should not be confused with \INST1 type instances seen in MSSQL Configuration, which is what I think you may be thinking of.

It would be good practice to keep your CAs separated, because if all were on one host, should the host be compromised all CAs on the host are compromised.

If you had multiple PKI trees in your Forest, your would see multiple entries from certutil.

There is the ability to decouple the Enrolment Policy server using the Web Policy Enrolment Server - useful for DMZ Environments where you need to issue certificates externally.

1
  • I added detail on why I think it's a good idea to consolidate instances... namely the 2nd tier will scale out horizontally with 10,000 + nodes. Jul 8, 2014 at 12:16
0

Its not technically possible to have more than one PKI hierarchy on one server and its a bad idea from a security perspective as has been mentioned (single point of failure). The ADCS role ties into the server's identity in AD such that the only way to alter the DN of the hierarchy would be to blow the role away and start over.

As far as licenses go, I don't believe the offline root CA needs to be anything special. You could technically generate the key material on a Linux host and publish it into AD from your enterprise issuing CA as long as the CRL and AIA endpoint matched up.

1
  • I got rid of the wording PKI hierarchy and clarified that I'm focused on consolidating policy servers. In my case I'm allowing each customer (of which I have 10,000 - 50,000) to generate their own certificates, given the constraints existing in the policy server (EKU/Name constraints) Jul 8, 2014 at 12:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .