Error message

Notice: Undefined index: localized_options in menu_navigation_links() (line 1861 of /net/council/home/www/drupal/includes/

Schannel Event ID 36869 ".... does not have private key information ..."

What a fun one this was to troubleshoot, thanks one again M$!

The error for me was being triggered when people tried to connect via LDAPS (not the commonly found results for HTTPS although much of the information here likely overlaps).

Here are all the articles I used for reference to solve this, I had to piece some things together and use the diagnostic info on some of them to get the full picture:

* - this is another article I wrote on my site because I had to fix up my CA config before I could get through my info below

* Use a self-signed certificate from your domain CA (directions below comment somewhat if doing otherwise)
* Use DC as the CA if you wish, or not, M$ suggests not doing that but how many 'servers' do we all have to dedicate to M$ domain services? My setup uses a DC as the CA

Now, here's what I actually had to do:
using linux you test to see if your server is in a similar state by using (to test in Windows, find a test, some of the links above discuss using the Ldp.exe tool which should indeed fail to connect on SSL option if it is not properly working...... obviously there could also be other reasons for failed connections using that tool, so test accordingly):
openssl s_client -showcerts -connect
if you are in a similar state you will get no information returned (or invalid info) where it should be showing the CA cert. also, when you issue this command you should get an Schannel error logged in windows server event log. if you instead have CA cert info spewing out and logical information alongside it, you may have ldaps set up correctly and may be having a client issue instead. however, i wonder how you ended up reading this topic since it is entitled and describing the 'Schannel' windows server error.

So, you're in a broken state, as validated above, you need to follow the info in one of the MS links I provided above to (using the command line section for most explicit directions:

create a cert request template file as named 'certnew.req' as an example:

Signature="$Windows NT$

Subject = "" ; must be the FQDN of domain controller
EncipherOnly = FALSE
Exportable = FALSE ; TRUE = Private key is exportable
KeyLength = 1024 ; Common key sizes: 512, 1024, 2048,
; 4096, 8192, 16384
KeySpec = 1 ; Key Exchange
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

; Omit entire section if CA is an enterprise CA
OID= ; Server Authentication

CertificateTemplate = WebServer ;Omit line if CA is a stand-alone CA

In this file:
* you MUST have the FQDN of the Domain Controller (DC) where you are troubleshooting this error as either the 'subject' or as the '''first''' entry on the 'SAN=' line or M$ will ignore the cert when trying to decide which one to use for the LDAPS service on 636 when initializing it (yes, it is documented and I proved it as true)
* you want to use the 'CertificateTemplate' line if you are using an 'Enterprise Level CA'
* i used 2048 key length as 1024 is getting a bit insecure these days, but it's no matter really
* you can actually have other SAN names for additional DNS names that can use this key for the LDAPS session setup ( for example) but you '''must''' have the DC's FQDN as the subject or first SAN option!!!
** '''to use SAN option do this on your CA server first''' (from command line)
** certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
** net stop certsvc
** net start certsvc

Next, you must use windows command line utils to generate and request a signed cert from this setup. You '''must''' perform these commands from the machine where you will be installing the certificate (on the same DC that you are troubleshooting for instance and where the errors occur in DS)
certreq -new certnew.inf certnew.req

Ok, that created the certnew.req file which is used in the next command to get it signed from a CA
certreq -submit certnew.req certnew.cer

Now, in that folder should be a signed 'certnew.cer' that has public key info.

The command is written there will pop up one interactive interface, you can use the '-client' option as documented on the M$ link at top to see how to do this if you wish for it to be entirely non-interactive. Also, you can get it signed from the 'req' file using other methods if you are using a 3rd party CA, however, it's '''TERRIBLY''' important to keep track of the private key during this process if you don't use this CLI. If you do use this CLI M$ will handle the private key automagically, which is why it's important to perform these commands on the machine where you are fixing the 'Schannel' error.

OK, finally, you need to follow the small section at the bottom of one of the M$ links above that details how to add the key to Windows Server 2008 R2 (unless you are not using 2008 R2, then follow the directions for your OS). Technically 2008 R2 claims it's better to install the certificate locally in the certificate manager for the 'Service' 'Active Directory Domain Services' service, so ...
# Start --> Run --> MMC
# Add/Remove 'Certificates' snap-in, 'Service Account', 'Local Computer', 'Active Directory Domain Services'
## This is where directions would differ slightly for non 2008 R2 servers
# Expand 'NTDS\Personal'
# All Tasks --> Import...
# Import your new '.cer' that was just saved in CLI steps above
# Finally, the .cer should show up with a tiny 'key' icon layered over the picture of the cert indicating it has Private Key information

Now, according to M$ (and according to what happened when I did it), in 2008 R2 only, the certificates are immediately updated and the LDAPS service will begin using that new cert. Here are the catches from this section of logic (this logic is specific to Windows Server 2008 R2, logic prior to that OS is different but documented in the links above for other OSs) :
# M$ will use the certs found in NTDS\Certificates before using what is found in Certificates (Local Computer) Personal, this is why the info above discusses using the 'Active Directory Domain Services' storage location when finally importing your cert
# M$ then selects the cert with the expiration date furthest in the future if there are multiple matching certs
## The idea here is that if you generate a newer cert and put it in that cert storage manager you would want to use that newest cert when selecting amongst the list

So, if you've gotten here your server should be working now and that error should go away. You can use my very first step to see if you have any different results when trying to connect. Also, check windows error logs after trying to see if 'Schannel' errors re-surface.

That is all... but for my environment where I have 2 DCs I had to generate 2 certs using this set of steps uniquely on each server such that the FQDN matched up and was imported into the certificate store on each DC completely separately. Then.... finally.... services were happy.

Man this cert stuff can be a headache when M$ does so much automatically =( Why not just let us pick which public and private key to use? I know it'd be so difficult for system admins to then have to understand what they are trying to do and what they're setting...... but that's our job isn't it?