Posts on this page:
Updated 20.06.2018: clarified the purpose of NTAuthCertificates DS container.
Hello folks! Today I want to explain in details about Active Directory containers related to ADCS (Active Directory Certificate Services), their purposes and how they work.
All ADCS related containers are stored in configuration naming context under Public Key Services container:
CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}
Since Public Key Services container is stored in configuration naming context, any it’s content is replicated between all domain controllers in the current forest (not only current domain) and are available to any client in the forest. This means that there is no way to limit PKI containers only to specific domain or domains.
Here is a screenshot from ADSIEdit.msc tool:
Hi again! Recently I faced an issue with my Test-WebServerSSL function which is also available in my Powershell PKI module.
In certain cases, the function returns certificate chain errors, while Internet Explorer (as well as other web browsers) works normally and do not report anything wrong. For example, you can open https://www.nic.lv/ web site without any issues in your web browser. When you run Test-WebServerSSL function against this web site, you get the following:
Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.
When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).
The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins:
Hello S-1-1-0 again, I'm back!
In the first part we discovered basic OCSP requests and responses. Today's stories:
By default, Online Responder may pre-cache OCSP response for particular certificate, especially if the certificate is used very frequently (for example, SSL certificate at login.live.com) until it (response) is expired. This reduces server load, because there is no need to sign the same response for each incoming request. And this behavior is recommended by RFC5019. Here is an example for StartSSL/StartCom SSL certificate:
Hello folks, PowerShell Crypto Guy is again on the board! Today I want to talk about a useful OCSP Client Tool which is available in my PowerShell PKI module.
A time ago I started Online Responder deployment and was faced the problem that there are no good tools to test it's configuration and how it works. PKIView.msc and certutil.exe just can tell whether the OCSP is functional or not. No details about request and/or response details. After a little research I found pretty useful and nice tool called Ascertia OCSP Client Tool. Actually this is a great tool with a lot of powerful features, including raw ASN.1 traces and so on. I thought that it is worth to buy the tool and contacted their sellers. Holy ****, the price killed me. They asked about 1,800 (1.8k) euros for a single license! Even though the tool is very cool, I wasn't ready to spend such money for it. But, if you manage Lorne Greene or Johnny Cash, then Ascertia's product may be for you.