One friend of mine asked about how to get signature creation time in PowerShell. When we sign a file, optionally (but recommended) we can timestamp the signature, thus approving that the file was signed at the certain moment and wasn't re-signed later. Some useful details about signatures and timestamps you can read in my previous article: Digital signatures.

Here is what we see in the UI:

We see the following fields:

A time ago, Windows PKI team posted an article about a tool that allows you to check web server SSL certificate: Verifying The SSL Certificate Expiration with a tool. Unfortunately, the download link is broken. I have this tool and uploaded it to my weblog: VerifySSLCertificate.

• ZIP archive SHA1 hash: C633A3DC3E8A3AA6BDD714EABB925429076A160A
• Executable SHA1 hash: A13CE031F5C1331785E87B62D1464C6260549EC0

The tool is very good, but what if you want to run the test against a bulk of servers? Any sort of automation and batching means some PowerShell stuff :). To provide administrators with such tool I wrote a PowerShell script, where you can test web server SSL certificate and it's status. You can export required fields to XML or CSV for future examination/audit. Let's go:

At first, I want to mention that you can use the following CMD commands:

• certutil –ping

Pings certificate management (ICertAdmin) and enrollment (ICertRequest) interfaces. Optionally you can ping remote CA interfaces: certutil –config CAHostName\CAName –ping

What if you want to do this programmatically? Nice question! Looking to CryptoAPI reference you can find the following methods: ICertAdminD::Ping and ICertRequestD::Ping methods. However, local COM interfaces does not support these methods. Workarounds? PowerShell has workaround! Here is a simple code example, that tests CA and interface availability:

Hello мир! Yesterdays I've published another version of my PowerShell PKI module — v1.0. Here are release notes:

Installation experience

I've spent much time on reviewing existing installation experience. My main goals were:

• Provide a single package for different platforms — x86 and x64.
• Support direct updates (without requiring to manually remove previous installation).
• Provide custom installation scenarios — for current user or for all users.

As you may be noticed, previously I've used Advanced Installer (thanks to PowerShell MVP Shay Levy who advised me this product) to wrap my package in MSI. Advanced Installer has intuitive, well-designed (attractive) and rich UI and this product is (possible) the best for beginners like me. However, free license is not enough for custom installation scenarios (like 32/64-bit mixed packages, direct upgrades, patching and so on). In order to accomplish these goals, I've contacted Caphyon Advanced Installer team for some support here. Advanced Installer support was very quick and kind, so I'm ready to provide new installation experience.

Hi S-1-1-0, PS Crypto Guy is again on the board! Today I want to discuss about implementing Online Responder for Root and Policy CAs.

Abstract

Online Responder implements Online Certificate Status Protocol (OCSP) as a part of alternate certificate validation mechanism (or revocation provider). Classic PKI uses Certificate Revocation Lists (CRL) to provide an information about revoked and untrusted certificates issued by the particular Certification Authority (CA). Most applications perform certificate checking for revocation by downloading and examining the particular issuer's CRL (or CRLs). If the presented certificate's serial number is listed in the corresponding issuer's CRL, an application rejects that certificate. During the CA lifecycle, you sometimes revoke some unnecessary and untrusted certificates. For example, if a certificate holder lost his/her certificate and associated private key, or a user left the company. Each revoked certificate's serial number is added to the CRL.