Posts on this page:
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.
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.
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.
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: