Re: TLS not accepting CRL

Hi Michael

We do not do any form of authentication of the client machine using
certficates. We do however perform a check of the SSL certifcate the server
has (if set). But the client doesn't check the CRL of the servers
certificate. There are number of areas within Windows where we don't check
the CRL because this is a long process.

So i have some questions:

1) Why is client CRL checking of the servers CRL essential to your scenario?
2) Client CRL checking of the server cert would add several seconds to the
connect time would this be accptable if was enabled?
3) Mutual-auth - why is mutual auth (or the client using certificates)
important to your scenario. Client certs can be enabled for non TS roles
such as IIS but experience has show that this are very rarely used.

It would be great for me to understand if these are essential requirements
for your scenario and why.

regards

--
Alex Balcanquall
Technical Product Manager
Terminal Services
Windows Server System

http://www.microsoft.com/ts
http://www.microsoft.com/windowsserver2003/partners/termsrvs.mspx

This posting is provided "AS IS" with no warranties, and confers no rights.



"MichaelW - Melb.Aus." <MichaelWMelbAus@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:DB3CE27B-DD07-4B44-B67B-657124B4CDA9@xxxxxxxxxxxxxxxx
> Thanks for your prompt response - I had looked at that document (one of
> many)..
> I am a little confused however.
> Isn't the whole purpose of using TLS for client authentication? (we
> already
> have encryption with RDP/TS). In essence from what I read is that the TS
> will
> not check the CRL before establishing a TLS session.
> In my eyes that seems to go against the whole being of a Trusted
> environment.
>
> Am I reading this all wrong, or does TS truely not care about the CRL of a
> CA?
>
> The way I read it:
> I have a user on my network working from home - I allocate them a cert and
> the msrdp52.msi and tell them to log on... fine! (That works)
> However, that person leaves my company. I can't force them to delete the
> file. I can force them to delete their certificate. I can't force them to
> even update the CRL from the CA.... but I CAN revoke their certificate -
> meaning: their certificate is no longer trusted.
>
> I would have thought that when a client establishes a TLS session to the
> Terminal Server - it would check the certificate, then check the CRL to
> see
> if that certificate is revoked...
>
> aparently this is not the case....
> does anyone not find that weird?!
>
> Maybe I am doing something wrong?! Has anyone actually got a certificate
> to
> revocate and stop tls sessions?
>
> I'll keep digging - this can't be a design flaw.
>
> Once again, Vera, despite my frustrations - I appreciate your response.
>
> "Vera Noest [MVP]" wrote:
>
>> I have not used TLS myself, but this article seems to describe what
>> you see: it is the certificate on the server which is checked, not
>> on the client.
>>
>> 895433 - How to configure a Windows Server 2003 terminal server to
>> use TLS for server authentication
>> http://support.microsoft.com/?kbid=895433
>>
>> _________________________________________________________
>> Vera Noest
>> MCSE, CCEA, Microsoft MVP - Terminal Server
>> TS troubleshooting: http://ts.veranoest.net
>> ___ please respond in newsgroup, NOT by private email ___
>>
>> "=?Utf-8?B?TWljaGFlbFcgLSBNZWxiLkF1cy4=?=" <MichaelW -
>> Melb.Aus.@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 22 aug 2005 in
>> microsoft.public.windows.terminal_services:
>>
>> > Maybe I have all of this wrong..
>> > Network:
>> > Windows2003 w/ Terminal Services
>> > Windows 2000 w/ Certificate Services (legacy - due to be
>> > upgraded by not slated for >months)
>> > XP w/ TSClient 2.5+
>> >
>> > I have the server and workstation communicating with each other
>> > when I use TLS.
>> > When I revoke teh certificate (and check that the certificate is
>> > revoked) - the client still connects.
>> >
>> > Does the TLS on the terminal server actually check the
>> > revocation of the certificate? I have checked the local cert
>> > profile, and find the revocation listed (with my revoked
>> > certificate) - but I can still connect.
>> >
>> > Have I got this wrong? from what I see, the TLS is looking to
>> > see if the SERVER's certificate is valid (and doesn't care less
>> > if mine - the client's - is or not).
>> >
>> > What I am trying to design is a way that I can roll out client
>> > connections to many of our users "home" machines - without
>> > having to install software.
>> >
>> > As a side point - I see from one of the threads, that tsweb
>> > doesn't seem to support tls... any idea if that will ever
>> > change? Really nice way to publish a terminalserver!
>> >
>> > Thanks in advance.
>>


.

Relevant Pages

  • Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle
    ... SSL only validates you are talking to a SSL certified server; ... They can simply edit the URL the client program ... can be done by using a X.509 certificate on both ends, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: LDP client authentication fails
    ... I got the LDP working with LDAP server under server client authentication ... I did not installed the certificate in pfx format .. ... Client cert auth won't work without that. ...
    (microsoft.public.windows.server.active_directory)
  • Re: SSL & Man In the Middle Attack
    ... >> it possible for the middle man to intercept all messages from server to me ... > server sends client a signed message along with a digital certificate. ... > client generates a random secret key, ...
    (comp.security.misc)
  • Re: activesync issue
    ... On the SBS 2003 Server open the Server Management console. ... On the "Web Server Certificate" page, choose to create a new Web server ... Install the new certificate which created in above step on mobile device: ... Access to browse the Exchange Server 2003 client after you install ...
    (microsoft.public.windows.server.sbs)
  • Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle
    ... order to detect we are connected to the wrong server (even though its SSL ... certificate is OK and valid by Verisign); we would need a client certificate. ... this can be detected by SSL/HTTPS client in ...
    (microsoft.public.dotnet.framework.aspnet.security)