I think, I have to publish several articles that would cover common PKI/ADCS administration tasks with PowerShell by using my PowerShell PKI module (of course!). Today I'll cover very simple, but very common task: managing pending certificate requests.

In this post we would propose the following scenario:

• IIS admin requested certificate for internal SharePoint portal
• Certificate template is configured to require CA manager approval to issue the certificate.
• No certificate will be issued until CA manager review and approve the request.

Just to make it clear, CA manager approval is configured in the certificate template, as follows:

you, as CA manager, received notification about incoming certificate request. Your task is to review the certificate request to ensure that it is properly constructed and conforms internal security policies and then make decision: approve or deny certificate request. You can do this by using Certification Authority MMC snap-in, but this would require a lot of clicks and without having a chance to automate this. Another solution that includes PowerShell offers you great automation capabilites.

Recently I was asked about how to read Enrollment Agent Rights and Certificate Manager Restrictions in ADCS. At first, I would like to make a little introduction about the subject.

Enrollment Agents

With Active Directory Certificate Services (ADCS) you can designate one or more enrollment agents to enroll on behalf of other users. One of the most common scenarios is smart card provisioning. Suppose, you purchased smart cards and plan to issue them to employees. You will designate one or more highly trusted persons who will:

• instruct employees about smart card usage policies;
• register smart card serial number/other data in the accounting system (some certificate lifecycle management system);
• prepare smart card for use (print labels and so on);
• install certificate for another employee.

Enrollment Agent Restrictions cover the last point in the list. Restrictions define three major parts:

I’m glad to announce that today I switched my website to SSL. This greatly increases security for my visitors, because all your data on this website is protected.

I made a soft-permanent redirect from HTTP to HTTPS. This means that all previous links to my website will continue to work, but with redirect. In any way, I encourage everyone who have links to my website to update them by changing protocol identifier.

Please, let me know if you face any SSL-related issues when browsing my website, either, in the post comments, or by contacting me via contact form.

And the last word: many thanks to DigiCert as they kindly offered me SSL certificate. I’m using their services for several years and would say that it is really 5-star service with outstanding support lelvel and which is easy to use.

About the problem

PowerShell MVP, Adam Bertram with his recent tweet inspired me to write this blog post. I realized that I see a lot of articles which describe how to delete certificate from certificate store, but never saw article that would describe how to do it properly.

Let’s recall what is wrong here. Years ago I wrote a blog post: The case of accidentally deleted user certificates that describes steps how to restore deleted certificate with private key by having a backup certificate only with public key. I explained why you can use certificate with just public key to restore bindings to private key. The answer was: when you delete certificate by using standard means (certificate store management functions in CryptoAPI), the private key is not deleted! Standard tools includes: Certificates MMC snap-in, X509Store class in .NET, certutil, etc., all they use Certificate and Certificate Store Functions. Our goal now is to fill the gap and provide an ability to remove private key along with certificate when you work in PowerShell.

About the problem

Almost everyday we hear about SHA1 deprecation policy. Many commercial CAs now sign end-entity certificates with SHA2 (actually, SHA256) and. Some of them upgrade issuing CAs to SHA2. Many security administrators  move their private CAs and certificates to SHA2 signatures. Unfortunately, not all do this migration correctly. Companies just configure their CAs to sign certificates with SHA256. Is this enough? Actually, not.