We have an internal CA server for our domain located at http://cert_srvr.local.domain/certsrv/certrqxt.asp. This server runs Microsoft Active Directory Certificate Services.

When I went to the site, I was able to use a CSR that I made on a linux computer to request an advanced certificate issued to the DNS name of our web proxy server. I used the following command to create the CSR:

openssl req -new -newkey rsa:2048 -keyout key.key -out csr.csr

I think this is a security risk because my non-admin account credentials were passed through via NTLMv2 to the internal CA's Certificate Services site when I logged into it... and I was able to create a certificate as if I were the proxy server (IssuedTo: proxy-server.local.domain) even though I'm not.

Since all workstations on our domain have the MS AD CS server's certificate in their trusted cert store, the cert I made could be used in a MITM attack by pretending my PC was actually the proxy server. This would have to be used in conjunction with a DNS spoofing or other type of attack to get clients to believe my computer was the proxy server, but it is still possible that the certificate could be misused for redirected SSL traffic to be decrypted by a MITM machine.

Does this sound right, or is there no real security risk here?

2 Answers 2


Certificate Services is a configurable CA which works on the concept of certificate templates. A template describes a kind of certificate that the CA may issue, under what conditions and with what contents. If you could obtain a certificate from CS, then this means that you requested the certificate for a template for which you were allowed to request a certificate.

What matters, though, is what is in the resulting certificate. I invite you to take a look at the certificate contents (with openssl x509 -text). You may add a lot of things in the certificate request, but, ultimately, the template dictates what appears in the certificate itself. Possibly, the machine name you asked for (proxy-server.local.domain) does not actually appear in the certificate at all, or not where a SSL client would look for it. A SSL client requires that the server name (from the URL) appears in the Subject Alt Name extension as a dNSName; lacking a SAN extension, the client will use the CN part of the subject DN (this is described in RFC 2818).

If you could indeed obtain a certificate which, from the point of view of a SSL client, would be a valid SSL server certificate for a server whose name you choose, then yes, one can say that there is a security-related problem that should be fixed. The sysadmin should review the templates activated on the CA and their access rights.

The main security risk for a CA (any CA) is lack of proper system administration.


As Tom mentioned Windows Certificate Services relies on certificate templates to determine the types of certificates it can issue. Those certificate templates are actually AD objects and have permissions that you can change to permit or deny AD groups from requesting them. So it sounds like the admins at your company may need to tighten down permissions if enrollment cases like yours aren't desired.

In addition, the admins can restrict access to the CA Web interface, limiting normal user enrollment to only the Certificate Request (aka Certificate Enrollment) wizard function. I'm not positive, but I believe CSRs can only be submitted through the web interface. So removing this functionality can further limit the ability to request forged certificates.

You should also be able to require certificate manager approval for any submitted CSRs, giving admins time to verify that they contain legitimate data before approving them. Certificate Manager roles should be limited to authorized personnel familiar with the risks.

When SSL certs are requested through the Certificate Request function (and not the web interface) they can be strongly authenticated by AD that they are the server they say they are, at least as far as Windows DNS is concerned. It is possible to turn on Subject Alternative Names within certificate requests and that is risky since it would allow authorized users to potentially forge server names. You, or your admins, can read more about that in this Microsoft article.

I've seen a lot of organizations not take Certificate Services seriously enough. This is unfortunate because, as you mention, any cert it issues will be trusted by any AD client. It's important that admins are educated on the functionality and the risks so they can lock down certificate functionality appropriately.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .