(2019-02-08) Troubleshooting HTTPS/LDAPS

My ADFS environment has an attribute store configured to an ADLDS and for that I used the “ldapattributestore” that still is available in the codeplex archives (https://archive.codeplex.com/?p=ldapattributestore). Because that ADLDS instance was running on a DC with ADDS, I configured the ADLDS instance to use port 5389 for LDAP and port 5636 for LDAPS. The “connection" string” for that LDAP Attribute Store was configured to use a secure connection (i.e. LDAPS) over port 5636. As I was checking functionality of my test environment I also tested this part by targeting the “Show My Claims” app (https://jorgequestforknowledge.wordpress.com/2015/07/04/displaying-the-issued-claims-in-a-security-token-on-screen/) that dives into that LDAP Attribute Store and displays specific claims on screen.

As I did not use my test environment for some time, several certs were expired and needed replacement. I opened the Local Machine certificate store and replaced every certificate that was expired or was going to expire soon with a new certificate using the exact same subject and SANs. After updating all certificates I started configuring and testing every single application using a certificate. So as you can imagine at some point in time I ended up with ADFS, the Show My Claims web site and with that the LDAPS attribute.

As an initial test I accessed the Show My Claims web site and due to the Issuance Transform Rules ADFS needed to dive into the ADLDS attribute store to source claims being displayed on screen. Unfortunately that failed. Looking at the ADFS Admin Event Log, ADFS was having issues accessing the Attribute Store. Those issues were related to the usage of LDAPS.

In that case I needed to start the basic testing of LDAPS through the good old LDP and see what was going on.

–

So after starting LDP and entered the FQDN of the ADLDS instance and its configured LDAPS port   

Figure 1: Starting LDP And Connecting To The ADLDS Instance Using The FQDN, The LDAPS Port

–

After clicking OK I was not surprised about the error “cannot open connection”. The more interesting question was “WHY?”

Figure 2: Error When Connecting To The ADLDS Instance

–

For this ADLDS instance I had a certificate with a subject and SAN that contained “IDSTORE.IAMTEC.NL”. I also permissioned the corresponding private key with the service account being used by the ADLDS instance. So far so good, but even with that it did not work. That’s when I decided to check all the requirements of a certificate to be used for LDAPS and used the following Microsoft article:

• How to enable LDAP over SSL with a third-party certification authority

–

The certificate that I was using fulfilled all requirements and with that in mind it was time to enable debug logging for SCHANNEL when using HTTPS or LDAPS:

• How to enable Schannel event logging in IIS

–

To make sure I was not missing any information, I configured the following for debug logging of SCHANNEL:

• 0x0001 Log error messages
• 0x0002 Log warnings
• 0x0004 Log informational and success events

–

After enabling debug logging for SCHANNEL I tried it again with LDP and in the SYSTEM Event Log I saw the following error.   

Figure 3: Error When Accessing The Private Key

–

A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

–

I reconfirmed the certificate for IDSTORE.IAMTEC.NL had its private key configured for the service account in use by the ADLDS instance. It still did nit work

–

I also saw the following event in the SYSTEM Event Log

Figure 4: The Private Key Being Used By The ADLDS Instance

–

The TLS server credential’s private key has the following properties:

   CSP name: Microsoft RSA SChannel Cryptographic Provider
   CSP type: 12
   Key name: d40c17eadd0fb4c1e33541e54ebf55b1_c9c5687f-fc0b-4765-bc6d-2435ba59e1b2
   Key Type: key exchange
    Key Flags: 0x20

The attached data contains the certificate.

–

The event shown above mentioned the private key being used by the the ADLDS instance, but it still did not mention which certificate was being used. Switching to the details TAB, it told me more about the corresponding certificate that was being used. Going through the data I noticed it contained the SANs “*.IAMTEC.NET” and “*.IAMTEC.NL”. That was surprising to me as the certificate that envisioned for the ADLDS only contained “IDSTORE.IAMTEC.NL” as subject and as SAN.

Figure 5: The Certificate Data That Belong To The Private Key

–

After seeing this I remembered the following listed in the first MSFT article:

Multiple SSL certificates

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate

–

What I never realized was that my wildcard certificate was going to be used first before even considering the usage of the certificate that contained the more specific subject and SAN.

As displayed below I permissioned the private key that belonged to the wildcard certificate ….

Figure 6: Permissioning The Private Key Of The Wildcard Certificate

–

Retried my test with LDP as shown below….

Figure 7: Retrying The LDAPS Test With DP

–

….and now it worked. You can see at the top it is connecting securely through LDAPS and that it is using a cipher strength of 256 bits

–

After this I check the LDAP Attribute Store configuration to make sure everything was configured correctly. And it was. Retrying accessing the Show My Claims site I was able to the claims that were sourced from the ADLDS instance

Check!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2015-05-23) Generating Self-Signed Certificates (For Testing Purposes)

With MAKECERT you could create/generate self-signed certificates that you could use for testing purposes or in your test environmnt. MAKECERT has been deprecated for reasons described here. In Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2 you can use the New-SelfSignedCertificate CMDlet. However, that CMDlet has its own limitations. By default it uses the following hardcoded limitations, which unfortunately cannot be changed:

• Subject: Empty
• Key: RSA 2048
• EKUs: Client Authentication and Server Authentication
• Key Usage: Digital Signature, Key Encipherment (a0)
• Validity Period: One year

–

One of the best PKI guys I know about, is Vadims Podāns, and he wrote is own New-SelfSignedCertificateEx CMDlet a few years ago which quite some flexibility. For example, you can specify the "Not Before" and "Not After" date, and therefore determine the lifetime of the self-signed certificate. It is included in a PowerShell script, which can be downloaded from here.

–

Unfortunately, at the time of writing, I could not get it to work (Vadims version may have been updated, so always check his script first!). I got the PowerShell script working by doing the following:

• Downloading the PowerShell script
• Replace the line "function New-SelfSignedCertificateEx {" with "#function New-SelfSignedCertificateEx {"
• Replace the last line with a "}" with "#}" (line number 392)
• Remove the certificate block
• Change the execution policy in PowerShell

–

For my testing purposes I used the following PowerShell command (make sure to replace some parameter values with the values you need)

.\New-SelfsignedCertificateEx.ps1 -Subject "CN=TESTTOKEN.IAMTEC.NL" -EnhancedKeyUsage "Server Authentication","Client authentication" -KeyUsage "KeyEncipherment","DigitalSignature" -SubjectAlternativeName "DNS Name=TESTTOKEN.IAMTEC.NL" -StoreLocation "LocalMachine" -ProviderName "Microsoft Enhanced Cryptographic Provider v1.0" -AlgorithmName RSA -KeyLength 2048 -SignatureAlgorithm SHA256 -NotBefore $([datetime]::now.AddDays(-345)) -NotAfter $([datetime]::now.AddDays(15)) -FriendlyName "My Test Self-Signed Certificate" -exportable

Figure 1: Generating A Self-Signed Certificate With The Custom PoSH Script

–

My version of the PowerShell script with the changes mentioned above can be downloaded from here. All credits for this script go to the original writer of it, Vadims Podāns.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————