Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:

Recently I was tasked to configure SSL/TLS protocols and cipher suites for internal web servers via Group Policy. At first, we collected a list of web server and web client applications to determine the weakest possible SSL/TLS protocols. Once the list was complete, we deployed sample policy in test OU and finally applied them to the rest domain.

Now I was tasked to scan web servers to determine if they match new security policy. In order to minimize my effort in testing, I wrote a simple PowerShell script that accepts a list of web URLs and tests each host with a list of SSL protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. Here is a sample code:

Finally I did it! I burned my old SharePoint blog and R.I.P.?ed my former Russian blog (DasBlog) as promised.

The problem

Just to recall the history. Several years ago I realized that I need a new website/portal to host my stuff. Initially I looked for a ready solution that would match my humble requirements:

1. It should support hierarchical site directories to organize content;
2. It should support SQL database;
3. It should support multi-level hierarchical content categories;
4. It should support an ability to control rendering;
5. It should support old URLs and redirect to migrated cont...

SYMPTOMS

Consider the following scenario. You configured Software Restriction Policies (SRP) to allow run all applications that are signed by the specific signer by creating a Certificate Rule against the signer certificate.

When the policy is refreshed on the client, user cannot run the application, because it is blocked by Software Restriction Policies.

CAUSE

This behavior occurs when the certificate is issued by a Certification Authority (CA) which do not include or provide incorrect issuer information in the Authority Information Access (AIA) extension in the signing certificate. In addition, intermediate CA certificate is not installed in the local store. SRP reads only signing certificate in the digital signature and ignores the rest certificates.

Today I want to present another useful CryptoAPI functions to use when working with PFX (PKCS#12) certificates.

1. Determine if the BLOB is PFX without having to pass a password;
2. Test PFX password.

Of course, you can try to use appropriate X509Certificate2 class constructor, but this approach is faster and do not require key import in cryptographic provider and other actions performed by X509Certificate2 constructor. This functionality is implemented in two CryptoAPI functions:

1. PFXIsPFXBlob
2. PFXVerifyPassword

And here is complete solution: