PKI: using a private versus a public ca

2019-04-05 06:17:00

This morning an interesting question passed through the SANS Advisory Board mailing list:

"Looking for anyone that has done a cost benefit analysis, or just general consideration, of using a Public CA vs. a Private CA for a PKI deployment. Some vendors are becoming very competitive in this space and the arguments are all one-sided. So aside from cost, I’m looking for potential pitfalls using a public CA might create down the road."

My reply:

My previous assignment started out with building a PKI from scratch. I’d never done this before, so the customer took a gamble on me. I’m very grateful that they did, I learned a huge amount of cool stuff and the final setup turned out pretty nicely! I’ll try and tackle this in four categories.

UPSIDES OF PRIVATE PKI

• You can run isolated from the world, you are fully self-reliant.
• Certificates are “free”, you can makes thousands of certificates without paying someone a penny.
• Very direct and short lines of communications, everything stays inside your company.

UPSIDES OF PUBLIC PKI

• Managed services, you don’t have to worry about almost anything.

DOWNSIDES OF PRIVATE PKI

• TCO, “One does not simply fire up a CA!”
• Designing, building and managing a PKI is specialized work, your team will need training.
• Designing, building and managing a PKI is more than just technology! You have to define processes and policies.
• It’s very easy to make mistakes with long-term effects (ref. Mark Cooper’s "Top 10/20 PKI mistakes" presentation).

DOWNSIDES OF PUBLIC PKI

• Costs, you pay per certificate.
• Privacy, “certificate transparency” tells the whole world about the certificates issued to you. 
• Privacy, OCSP certificate validation sends traffic to the external OCSP validation hosts, giving information about your internal data flows. 

If your infrastructure needs to be cut off from the outside world, you will HAVE to run your own, private PKI. 

I’ve recently presented on the basics of PKI and on building your own PKI, be it for fun, for testing or production use. The most important take-away was: “If you’re going to do it, do it right!”. You do NOT simply fire up a Linux box with OpenSSL, or a single instance Windows Server box with ADCS and that’s that. If you’re going to do it right, you will define policy documents, processes and work instructions that are to be strictly followed, you’ll consider HA and DR and you’ll include HSMs (Hardware Security Modules). The latter are awesomely cool tech to work with, but they can get pricy depending on your wants and needs. 

Remember: PKI might be cool tech, but the point of it all is TRUST. And if trust is damaged, your whole infrastructure can go tits-up. 

kilala.nl tags: pki, work, sysadmin,

View or add comments (curr. 0)

Query ADCS (Active Directory Certificate Services) for certificate details

2018-11-01 18:44:00

I think Microsoft's ADCS is quite a nice platform to work with, as far as PKI systems go. I've heard people say that it's one of the nicest out there, but given its spartan interface that kind of makes me worry for the competitors! One of the things I've fought with, was querying the database backend, to find certificates matching specific details. It took me a lot of Googling and messing around to come up with the following examples.

To get the details of a specific request:

certutil -view -restrict "requestid=381"

To show all certificate requests submitted by myself:

certutil -view -restrict "requestername=domain\t.sluijter"

To show all certificates that I requested, displaying the serial numbers, the requestor's name and the CN on the certificate. It'll even show some statistics at the bottom:

certutil -view -restrict "requestername=domain\t.sluijter" -out "serialnumber,requestername,commonname"

Show all certificates provided to TESTBOX001. The query language is so unwieldy that you'll have to ask for "hosts >testbox001 and <testbox002".

certutil -view -restrict "commonname>testbox001,commonname<testbox002" -out "serialnumber,requestername,commonname"

A certificate request's disposition will show you errors that occured during submission, but it'll also show other useful data. Issued certificates will show whom approved the issuance. The downside to this is that the approver's name will disappear once the certificate is revoked. So you'll need to retain the auditing logs for ADCS!

certutil -view -restrict "requestid=381" -out "commonname,requestername,disposition,dispositionmessage"    

certutil -view -restrict "requestid=301" -out "commonname,requestername,disposition,dispositionmessage"    

Would you like to find out which certificate requests I approved? Then we'll need to add a bit more Powershell.

certutil -view -out "serialnumber,dispositionmessage" | select-string "Resubmitted by DOMAIN\t.sluijter"

Or even better yet:

certutil -view -out "serialnumber,dispositionmessage" | ForEach {

    if ($_ -match "^.*Serial Number:"){$serial = $_.Split('"')[1]}

    if ($_ -match "^.*Request Disposition Message:.*Resubmitted by DOMAIN\t.sluijter"){ Write-Output "$serial" }

    }

 

Or something very important: do you want to find certificates that I both request AND approved? That's a bad situation to be in...

certutil -view -restrict "requestername=domain\t.sluijter" -out "serialnumber,dispositionmessage" | ForEach {

    if ($_ -match "^.*Serial Number:"){$serial = $_.Split('"')[1]}

    if ($_ -match "^.*Request Disposition Message:.*Resubmitted by DOMAIN\t.sluijter"){ Write-Output "$serial" }

    }

 

If you'd like to take a stab at the intended purpose for the certificate and its keypair, then you can take a gander at the template fields. While the template doesn't guarantee what the cert is for, it ought to give you an impression. 

certutil -view -restrict "requestid=301" -out "commonname,requestername,certificatetemplate"

kilala.nl tags: work, pki, sysadmin,

View or add comments (curr. 0)