Posts on this page:
Many, many and many administrators request new certificates and mark private keys as exportable. Is this a good solution? Definitely no. Are there a reasons to do that? In most cases — no. Do I need to explain the subject? Definitely yes.
In many MS guides that are suited with custom certificate enrollment you may find certificate enrollment configuration INF file like this:
Update 09.03.2011: removed SAN attribute flag as it is not necessary.
Many of windows administrators requires to setup SSL on their web servers and mostly they wish to use certificates with the Subject Alternative Name extension that allows to map a single certificate to a multiple web sites. For example, you want to use a single certificate for https://www.domaon.com and https://owa.domain.com. In that case you need to have multiple subjects in the certificate. However X.509 certificates don't support multiple subject fields. To resolve this issue, Subject Alternate Name extension is used. You can add multiple (even wildcard) subjects to a certificate.
Recently I decided to perform little changes on my OCSP Responder. I'm using offline CA (root) and have configured to include OCSP URL to all issued certificates. But some time I haven't OCSP configuration for my root CA. And today I have completed all changes and now Root CA issues OCSP signing certs for appropriate OCSP configuration.
You can find required info about the subject on TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide or in AskDS blog: Implementing an OCSP responder: Part IV - Configuring OCSP for use with Standalone CAs. However both links contains incorrect settings, therefore I'll post correct steps.
Update 18.08.2010: added workaround at the bottom of the post.
Many Windows customers have received an error message in Application log when they try to update third-party root list. Prior to issue description I want to explain about the subject. Third-party root list is the list of third-party (non-Microsoft) root certification authorities (hereinafter CA) that participate in Microsoft Root Certificate Program. All these CAs are trusted by Windows and applications. About Program participants you can read the following article: Windows root certificate program members. You can add your own CAs to a trusted root list, but you cannot remove predefined CAs from computer. Therefore if new program member appears or retires, Microsoft issues update that will add or remove corresponding certificate to (from) Trusted Root CAs certificate container. Internally update contains a Certificate Trust List (CTL). Let's see the error message:
Update 23.08.2010: added workaround to resolve the issue.
Today one customer claimed that AppLocker rules are not worked for his environment. He just created simple path rule and it didn't work. I have investigated this issue and I'm able to confirm that AppLocker don't apply path rules to a folder that contains non-english letters. Here is an example how to reproduce this issue. Assuming you have default Windows 7 Ultimate/Enterprise installation with C:\Windows as a system root folder.