third-party certification authority

Question

third-party certification authority

Rising Flight 6,456

Hi All,

I am trying to generate an INF file for an LDAP (LDAPS) certificate and I am following the below Microsoft article:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority

I have around 25 Domain Controllers. I know I can add all DNS entries in a single line, but for easier validation and to avoid mistakes, I would prefer to list each DC on a separate line.

Many of our applications rely on LDAP/LDAPS, so I want to make sure this is done correctly. I am not sure whether the SAN section can be formatted this way, and I would appreciate guidance.

I would like to specify the SANs in a readable format, something like:

&dns=dc01.contoso.com
&dns=dc02.contoso.com
&dns=dc03.contoso.com

Below is the INF file I am currently using:

;----------------- request.inf -----------------
;----- requested on ALL DCs-----

[Version]

Signature="$Windows NT$

[NewRequest]


Subject = "C=US, ST=MYST, L=MYL, O=Contoso, OU=Domain Controllers, CN=ldap.contoso.com"
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}"
_continue_ = "&dns=dc01.contoso.com&dns=dc02.contoso.com&dns=dc03.contoso.com"

Is it possible to list each DNS entry on a separate line in the SAN section? 2.If so, what is the correct syntax for multiple continue lines? 3.Is this the recommended approach when generating LDAPS certificates for multiple DCs?

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Marcin Policht 82,360 MVP Volunteer Moderator

Create a separate request for each domain controller - you can include a single alias you want to use to connect to any of them by specifying it as SAN. In general, you would want to be able to revoke the corresponding certs for individual DCs - rather than being limited to revoking the cert for all DCs at the same time

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Rising Flight 6,456

is this correct approach do i need to include dns=ldap.contoso.com or not?

2.5.29.17 = "{text}"
_continue_ = "dns=ldap.contoso.com&"
_continue_ = "dns=dc01.contoso.com&"
_continue_ = "dns=dc02.contoso.com&"
_continue_ = "dns=dc03.contoso.com"

or

2.5.29.17 = "{text}"
_continue_ = "dns=dc01.contoso.com&"
_continue_ = "dns=dc02.contoso.com&"
_continue_ = "dns=dc03.contoso.com"

Below will be my inf file please do validate. i have added

_continue_ = "dns=ldap.contoso.com&"

;----------------- request.inf -----------------
;----- requested on ALL DCs-----

[Version]

Signature="$Windows NT$

[NewRequest]

Subject = "C=US, ST=MYST, L=MYL, O=Contoso, OU=Domain Controllers, CN=ldap.contoso.com"
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}"
_continue_ = "dns=ldap.contoso.com&"
_continue_ = "dns=dc01.contoso.com&"
_continue_ = "dns=dc02.contoso.com&"
_continue_ = "dns=dc03.contoso.com&"
_continue_ = "dns=dc04.contoso.com&"
_continue_ = "dns=dc05.contoso.com"

Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-01-24T13:22:33.6866667+00:00
Your syntax with multiple _continue_ lines is valid, and yes, you normally should include dns=ldap.contoso.com if clients connect using that name. The more important consideration is that you should not reuse the same INF for all DCs with all DC names in SAN.

The _continue_ mechanism in a certreq INF file simply concatenates strings. Multiple _continue_ lines are appended in order, exactly as if they were written on one line. This means your SAN formatting is syntactically correct as long as:

each entry is prefixed with dns=

entries are separated with &

the last entry does not require a trailing & (it is harmless but unnecessary)

So this should work:

2.5.29.17 = "{text}" _continue_ = "dns=ldap.contoso.com&" _continue_ = "dns=dc01.contoso.com&" _continue_ = "dns=dc02.contoso.com&" _continue_ = "dns=dc03.contoso.com"

Functionally, this is identical to a single long line.

However, there is a more important part - what SANs should actually be in an LDAPS certificate. For LDAPS on a domain controller, the certificate is validated against the DNS name the client uses to connect. That means:

If applications connect to ldap.contoso.com, that name must be present in the SAN

If applications connect directly to dc01.contoso.com, that name must be present

The CN is ignored by modern clients - it's SAN that matters. So including dns=ldap.contoso.com is correct if that is a real DNS record (usually a CNAME or load-balanced name) that clients actually use. What is not recommended is issuing one certificate per DC that contains all other DC names. That creates operational and security problems:

You cannot revoke a single DC’s certificate without impacting all DC names in the SAN

You increase blast radius if a private key is compromised

You are deviating from Microsoft’s intended per-machine certificate model

The recommended model is one certificate per DC, so SAN contains the DC’s own FQDN

optionally one shared alias like ldap.contoso.com if clients use it. Example for dc01:

2.5.29.17 = "{text}" _continue_ = "dns=ldap.contoso.com&" _continue_ = "dns=dc01.contoso.com"

dc02 would get its own request and certificate with dc02.contoso.com, and so on.

Your posted INF file is syntactically valid, but architecturally it is not what you want if the same file is used “on all DCs” with every DC listed. If your intent is one cert per DC, then your structure is fine, just remove the other DC names and keep only:

ldap.contoso.com (shared alias, optional)

the local DC’s FQDN (required)

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Marcin Policht 82,360 Reputation points MVP Volunteer Moderator

2026-01-27T12:03:10.59+00:00
Your INF is mostly fine, but the SHA-1 warning usually means the CSR was not actually signed with SHA-256 despite what’s written in the file.

A CSR has two different “hash” contexts people mix up:

the hash used to sign the CSR itself

the hash the CA will later use when issuing the certificate

As far as I can tell, the error you’re getting (“Failed – using weak SHA1 algorithm”) refers to the CSR signature algorithm. Decoding tools check the CSR’s Signature Algorithm field (for example sha1RSA vs sha256RSA). If that field is SHA-1, the CSR is flagged as weak even if the CA would issue a SHA-256 cert.

In your INF, this line is correct in principle:

HashAlgorithm = SHA256

However, the provider you are using is the legacy CryptoAPI provider:

ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12

With legacy CSPs, Windows will often still sign the CSR using SHA-1 unless explicitly forced by the OS version and certreq behavior. On older templates or older Windows builds, the HashAlgorithm setting can be ignored.

To get a SHA-256–signed CSR, you should use a CNG (KSP) provider instead of a CSP. For example:

ProviderName = "Microsoft Software Key Storage Provider"

and remove ProviderType entirely when using a KSP.

After regenerating the CSR, verify it with:

certutil -dump request.csr

Look specifically for:

Signature Algorithm: sha256RSA

If it still says sha1RSA, the CSR is weak regardless of the INF contents.

One more important note: even if your CSR were SHA-1, a modern Microsoft CA can still issue a SHA-256 certificate. The CSR hash does not control the certificate’s signature hash; the CA template does. But many security tools reject SHA-1 CSRs outright, which is likely what you’re running into.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

i have generated the csr, when i decode it i am seeing this error.

csr

i have added HashAlgorithm = SHA256 in inf file, is this ok, can anyone validate

;----------------- request.inf -----------------
;----- requested on ALL DCs-----

[Version]

Signature="$Windows NT$

[NewRequest]

Subject = "C=US, ST=MYST, L=MYL, O=Contoso, OU=Domain Controllers, CN=ldap.contoso.com"
KeySpec = 1
KeyLength = 2048
; Can be 1024, 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}"
_continue_ = "dns=ldap.contoso.com&"
_continue_ = "dns=dc01.contoso.com&"
_continue_ = "dns=dc02.contoso.com&"
_continue_ = "dns=dc03.contoso.com"

Share via

third-party certification authority

1 additional answer

Your answer