SSL with AD LDS doesn't work / cipher problem?

Hi,

I'm currently trying to get SSL on AD LDS on W2K8 R2 x64 up and
running. I already have installed a certificate for the AD LDS service
account. When I use LDP.EXE on the local system, I can get an SSL
connection without any problem. When I use LDP.exe on a different W2K8
system, I can also get an SSL connection without any problems. So the
certificate is ok and the connection to the system works as well.

However, I need to create an SSL connection from a W2K3 system to my
AD LDS on W2K8. And this always fails. It also fails from a java
application - the is the application that finally needs to access the
AD LDS system.

I looked at the AD LDS event log and found the following error
message:
Client network address:
192.168.105.10:4614
Protocol:
TCP

Additional Data
Error value:
2148074289 The client and server cannot communicate, because they do
not possess a common algorithm.
Internal ID:
c050707


When I look at the data that Wireshark captures, I can see a SSL v2
Client Hello, but afterwards the server terminates the connection. The
SSL v2 client hello contains a number of Ciphers, where at least some
should be known by the AD LDS system.

When I look at the captured data from the W2K8 system where the
connection works, I can see an SSL (not v2) handshake, that contains
some more ciphers (e.g. with AES, which are not present in the client
hello of the W2K3 system).

Can anybody give me hint what I need to do in order to be able to use
SSL connections from the W2K3 system? Thanks a lot in advance!

Best regards
Holger

Are you connecting with the host name in the certificate or using the ip
address?

Try the fqdn matching the certificate if not already using that method.


Thoronox wrote:
> Hi,
>
> I'm currently trying to get SSL on AD LDS on W2K8 R2 x64 up and
> running. I already have installed a certificate for the AD LDS service
> account. When I use LDP.EXE on the local system, I can get an SSL
> connection without any problem. When I use LDP.exe on a different W2K8
> system, I can also get an SSL connection without any problems. So the
> certificate is ok and the connection to the system works as well.
>
> However, I need to create an SSL connection from a W2K3 system to my
> AD LDS on W2K8. And this always fails. It also fails from a java
> application - the is the application that finally needs to access the
> AD LDS system.
>
> I looked at the AD LDS event log and found the following error
> message:
> Client network address:
> 192.168.105.10:4614
> Protocol:
> TCP
>
> Additional Data
> Error value:
> 2148074289 The client and server cannot communicate, because they do
> not possess a common algorithm.
> Internal ID:
> c050707
>
>
> When I look at the data that Wireshark captures, I can see a SSL v2
> Client Hello, but afterwards the server terminates the connection. The
> SSL v2 client hello contains a number of Ciphers, where at least some
> should be known by the AD LDS system.
>
> When I look at the captured data from the W2K8 system where the
> connection works, I can see an SSL (not v2) handshake, that contains
> some more ciphers (e.g. with AES, which are not present in the client
> hello of the W2K3 system).
>
> Can anybody give me hint what I need to do in order to be able to use
> SSL connections from the W2K3 system? Thanks a lot in advance!
>
> Best regards
> Holger

--
/kj

Yes, I'm using the FQDN on when connecting from W2K3 and W2K8. The
FQDN is working fine, because otherwise I would not be able to open
the SSL connection from W2K8.

I think this must somehow be a problem of the ciphers in the Client
Hello message or the SSL version that is being used.

Hi

try bumping the logging level of the Schannel provider [1] on the W2k3
server (requires
server restart) and then running ldp against the AD LDS SSL port on the W2k8
box,
then look for Schannel messages in the System event log of the W2k3 server.

I tried a repro with a W2k3 SP2 member of a W2k8 domain accessing an AD LDS
instance running on a W2k8 SP2 member server with a server certificate on
that AD LDS
instance issued by an W2k8 enterprise CA and got a good handshake using
ldp.exe

Lee Flight

[1] http://support.microsoft.com/kb/260729

"Thoronox" <thoronox@gmail.com> wrote in message
news:ec5c2d21-658d-4cc8-9f37-64f75a0b2075@c3g2000yqd.googlegroups.com...
> Yes, I'm using the FQDN on when connecting from W2K3 and W2K8. The
> FQDN is working fine, because otherwise I would not be able to open
> the SSL connection from W2K8.
>
> I think this must somehow be a problem of the ciphers in the Client
> Hello message or the SSL version that is being used.

Hi Lee,

below you can already find a screenshot of the capture and the capture
itself:

http://www.mediafire.com/file/onx5ennauot/ssl.cap
http://www.mediafire.com/file/4z2lfyhmk2t/wireshark.bmp

The first 5 lines in the capture show the failed SSL connection from
W2K3, the remaining lines show the successful connection from W2K8.

I will increase the SCHANNEL logging and post the results.

Best regards
Holger

Hi Lee,

I checked the W2K3 SSL client, but it was only showing that SSL
credentials were created.

But I found something on the W2K8 AD LDS Server:

An TLS 1.0 connection request was received from a remote client
application, but none of the cipher suites supported by the client
application are supported by the server. The SSL connection request
has failed.

BTW: my W2K3 client is not in the domain of the W2K8 server.

Best regards
Holger

Hi,

I did some tests with the cipher settings in gpedit.msc and found out
that even from W2K8 no connection is possible, when I enabled all
ciphers except the ones with ECDHE.

So it seems that the server for whatever reason only accepts ECDHE
ciphers and blocks all other ciphers. The ciphers that are currently
enabled on the W2K8 server are:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA

At least some of them are sent in the SSL client hello. Any ideas?

Hi

I had not picked up that the W2k3 server is not a domain member,
unfortunately I'm away from the test rig where I ran that test for
a few days. However I did try a W2K3 server (not SP2) against
a W2K8 R2 DC that had a cert issued from a windows enterprise
CA.

Once I had imported the cert for the Windows CA into the
Trusted Root CA store for the non-domain client I got an LDAP
SSL connection from the W2K3 box to the DC using ldp.exe.
Schannel logging on the W2k3 box reported:

Protocol: TLS (SSL 3.1)
Cipher: RC4
Cipher Strength: 128
MAC: SHA
Exchange: RSA
Exchange Strength: 2048

I have not had a chance to test this against an AD LDS member server yet.

Do you have any other (non-default) security settings in your domain or
local security policy
that might be causing a problem e.g. requiring FIPS compliance [1]?

Lee Flight

[1]http://support.microsoft.com/kb/811833


"Thoronox" <thoronox@gmail.com> wrote in message
news:0b024b15-81f5-45c1-814f-c9ccfb110c83@v30g2000yqm.googlegroups.com...
> Hi Lee,
>
> I checked the W2K3 SSL client, but it was only showing that SSL
> credentials were created.
>
> But I found something on the W2K8 AD LDS Server:
>
> An TLS 1.0 connection request was received from a remote client
> application, but none of the cipher suites supported by the client
> application are supported by the server. The SSL connection request
> has failed.
>
> BTW: my W2K3 client is not in the domain of the W2K8 server.
>
> Best regards
> Holger

Hi Lee,

thanks for your hints. In the meantime we have been working with
Microsoft Support on this issue. It turned out that there was somehow
a problem with the certificate that has been created as PKCS#12 from
an OpenSSL CA. After generating the certificate request on the AD LDS
Server using certutil everything worked fine. I think Microsoft ist
still check whether this is a bug as the error message shown in the
event log is misleading.

Best regards
Holger

On Dec 21 2009, 3:31*pm, "Lee Flight" <l...@le.ac.uk-nospam> wrote:
> Hi
>
> I had not picked up that the W2k3 server is not a domain member,
> unfortunately I'm away from the test rig where I ran that test for
> a few days. However I did try a W2K3 server (not SP2) against
> a W2K8 R2 DC that had a cert issued from a windows enterprise
> CA.
>
> Once I had imported the cert for the Windows CA into the
> Trusted Root CA store for the non-domain client I got an LDAP
> SSL connection from the W2K3 box to the DC using ldp.exe.
> Schannel logging on the W2k3 box reported:
>
> Protocol: TLS (SSL 3.1)
> Cipher: RC4
> Cipher Strength: 128
> MAC: SHA
> Exchange: RSA
> Exchange Strength: 2048
>
> I have not had a chance to test this against an AD LDS member server yet.
>
> Do you have any other (non-default) security settings in your domain or
> local security policy
> that might be causing a problem e.g. requiring FIPS compliance [1]?
>
> Lee Flight
>
> [1]http://support.microsoft.com/kb/811833
>
> "Thoronox" <thoro...@gmail.com> wrote in message
>
> news:0b024b15-81f5-45c1-814f-c9ccfb110c83@v30g2000yqm.googlegroups.com...
>
> > Hi Lee,
>
> > I checked the W2K3 SSL client, but it was only showing that SSL
> > credentials were created.
>
> > But I found something on the W2K8 AD LDS Server:
>
> > An TLS 1.0 connection request was received from a remote client
> > application, but none of the cipher suites supported by the client
> > application are supported by the server. The SSL connection request
> > has failed.
>
> > BTW: my W2K3 client is not in the domain of the W2K8 server.
>
> > Best regards
> > Holger

Good news on the progress. Thank you for following up.

Lee Flight

"Thoronox" <thoronox@gmail.com> wrote in message
news:c33c892e-31c6-4e1b-a501-a0c8e678f231@c29g2000yqd.googlegroups.com...
Hi Lee,

thanks for your hints. In the meantime we have been working with
Microsoft Support on this issue. It turned out that there was somehow
a problem with the certificate that has been created as PKCS#12 from
an OpenSSL CA. After generating the certificate request on the AD LDS
Server using certutil everything worked fine. I think Microsoft ist
still check whether this is a bug as the error message shown in the
event log is misleading.

Best regards
Holger

On Dec 21 2009, 3:31 pm, "Lee Flight" <l...@le.ac.uk-nospam> wrote:
> Hi
>
> I had not picked up that the W2k3 server is not a domain member,
> unfortunately I'm away from the test rig where I ran that test for
> a few days. However I did try a W2K3 server (not SP2) against
> a W2K8 R2 DC that had a cert issued from a windows enterprise
> CA.
>
> Once I had imported the cert for the Windows CA into the
> Trusted Root CA store for the non-domain client I got an LDAP
> SSL connection from the W2K3 box to the DC using ldp.exe.
> Schannel logging on the W2k3 box reported:
>
> Protocol: TLS (SSL 3.1)
> Cipher: RC4
> Cipher Strength: 128
> MAC: SHA
> Exchange: RSA
> Exchange Strength: 2048
>
> I have not had a chance to test this against an AD LDS member server yet.
>
> Do you have any other (non-default) security settings in your domain or
> local security policy
> that might be causing a problem e.g. requiring FIPS compliance [1]?
>
> Lee Flight
>
> [1]http://support.microsoft.com/kb/811833
>
> "Thoronox" <thoro...@gmail.com> wrote in message
>
> news:0b024b15-81f5-45c1-814f-c9ccfb110c83@v30g2000yqm.googlegroups.com...
>
> > Hi Lee,
>
> > I checked the W2K3 SSL client, but it was only showing that SSL
> > credentials were created.
>
> > But I found something on the W2K8 AD LDS Server:
>
> > An TLS 1.0 connection request was received from a remote client
> > application, but none of the cipher suites supported by the client
> > application are supported by the server. The SSL connection request
> > has failed.
>
> > BTW: my W2K3 client is not in the domain of the W2K8 server.
>
> > Best regards
> > Holger