Posts on this page:
Hello folks, PowerShell Crypto Guy is again on the board! Today I want to talk about a useful OCSP Client Tool which is available in my PowerShell PKI module.
A time ago I started Online Responder deployment and was faced the problem that there are no good tools to test it's configuration and how it works. PKIView.msc and certutil.exe just can tell whether the OCSP is functional or not. No details about request and/or response details. After a little research I found pretty useful and nice tool called Ascertia OCSP Client Tool. Actually this is a great tool with a lot of powerful features, including raw ASN.1 traces and so on. I thought that it is worth to buy the tool and contacted their sellers. Holy ****, the price killed me. They asked about 1,800 (1.8k) euros for a single license! Even though the tool is very cool, I wasn't ready to spend such money for it. But, if you manage Lorne Greene or Johnny Cash, then Ascertia's product may be for you.
Hi S-1-1-0! Today I've released a new version of my PowerShell PKI module. It took a bit more that 1 month from previous release. I didn't expected to develop new version too fast. I just got a free time to work on my module and I had few ideas (mostly, based on customer feedbacks) which should significantly improve module usage area and user experience.
The major improvement in PSPKI v2 is Standalone CA and non-domain environment support. Now you can manage Standalone CAs in Active Directory domain or in workgroup environment. I tried several approaches to integrate this support to an existing Get-CertificationAuthority command. Eventually, I decided to create a new universal command which connects to a specified CA server (regardless, it is Enterprise or Standalone CA) — Connect-CertificationAuthority. The idea is that in most cases Enterprise CAs have almost similar configuration and Standalone CAs slightly different due to their different usage. Therefore, Get-CertificationAuthority is still used to manage Enterprise CAs and Connect-CertificationAuthority is used to manage a single CA instance, either Enterprise or Standalone. The output objects are the same (with an exception that Get-CertificationAuthority can return multiple objects) and its result can be piped to all commands that support pipeline input from Get-CertificationAuthority command.
This post summarizes the blog post series about certificate enrollment API (CertEnroll) and their usage in Windows PowerShell. The series covers all common enrollment API usage scenarios.
This post provides basic technical information about certificate requests, what they are, their structures and basic concepts.
In this post I'm talking about creating offline certificate requests with delayed submission (when client has no direct connection to CA server).
This post covers various ways how to submit request to Windows CA (both, Standalone and Enterprise), resolve issuance if the request is pending and how to install issued certificate to original client and associate it with generated private key.
This post describes the techniques how to enroll for a certificate for domain members by using certificate templates and Enterprise CA.
In this post I discuss about advanced enrollment called Enroll On Behalf Of another user. This method is usually used with smart card deployment.
This post provides some security information about request management and approval and exposes a useful techniques to create preconfigured self-signed certificates.
In addition, here are few real-life tasks that utilize CertEnroll in PowerShell:
This post covers how CertEnroll can be used to generate self-signed certificates for testing purposes.
This post shows techniques to configure remote IIS management with delegated (instead of default and insecure self-signed certificate) certificate from enterprise CA.
HTH
Other posts in the series:
Many of you already heared about a recommendation to place all requests where subject is supplied in the request in pending state for future revision and request approval by the CA manager. Many of PKI administrators consider this as a waste measure and do not follow this recommendation. Several of PKI administrators are aware about the security risk that the requester can put any subject in the request and they require manual approval of the certificate request. Though, they just check for Subject field and/or SAN extension in the request and approve the request if the subject looks like valid.
However there is less-known (but not less dangerous) risk that the requester has included wrong or inappropriate extensions. For example, with default Web Server template it is possible to issue a certificate for OCSP Response Signing. If the administrator is not too smart, a PKI can be compromised due to inappropriate certificate issuance. If you run Get-ExtensionList command from my PowerShell PKI module you will see two interesting properties: EnabledExtensionList and OfflineExtensionList:
Other posts in the series:
In previous posts we discussed and explored certificate enrollment APIs (CertEnroll) to perform various basic enrollment operations. In this section we will talk about advanced certificate enrollment called Enroll On Behalf Of (EOBO). This type of enrollment involves additional mechanism called registration authority (RA). This commonly is used during smart card deployments. For example, an employee prior to get a smart card is went through face-to-face interview with Enrollment Agent where he is instructed about smart card usage rules and is registered in accounting documents. After all formalities are completed, an enrollment agent creates a special certificate request where he put employee's user name (which is obtained from Active Directory) and signs it with his own special Enrollment Agent certificate. And only then the certificate request is submitted to a CA server.