Re: winsock + Schannel => Expired Intermediate Cert
- From: "John Banes" <jabanes@xxxxxxxxxxx>
- Date: Sun, 14 Oct 2007 21:31:00 -0700
I'd agree with this. I'll just add that the intermediate certificates from
the TLS handshake can be found in the certificate store referenced by
serverCert->hStore as obtained by QueryContextAttributes. Off the top of my
head, I'm not sure how you can pipe these to the UI code in question, but
I'm sure you'll figure it out.
Regards,
John
"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:eWBABEUDIHA.464@xxxxxxxxxxxxxxxxxxxxxxx
I'll take a guess as to what's going on here.
When you are using TLS for your SSL support (which you almost always are
these days since it is the default), the server can provide the entire
cert chain to the client instead of just the server's cert. This
basically means the client doesn't need to have ever possible intermediate
CA cert stored locally in order to trust a given server cert. As long as
the root cert in the chain is a trusted root and the chain as provided by
the server verifies, then the in-memory intermediate certs will do fine.
However, if you just open the server cert on the local machine outside of
the context of the SSL connection, the Windows cert UI will likely show
that the cert doesn't chain properly because the local store may not
actually contain the intermediate CA cert. In your case, there might be
an expired copy of the cert locally.
Typically, the browsers will display the cert chain as returned in the SSL
handshake and not the certs installed locally.
I'm not sure if that explains everything you are seeing, but maybe it
provides some insight.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"steve" <steve@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:99D07FB9-B6D0-4453-BF1A-1F642D1264EF@xxxxxxxxxxxxxxxx
[[ i posted this in the msdn forums, but this area seems to be a little
bit
more on-topic ]]
Hello,
I'm new to the Windows platform but have been developing Unix software
for
over twenty years - so if my questions are naive or make no sense, please
take that into consideration :-)
I've inherited some code that attempts to use winsock and the Schannel
APIs
to create an SSL connection to a well known server. However, after the
connection succeeds, I display the server certificate with
CryptUIDlgViewContext, and the dialog indicates that the intermediate
certificate for the site (us.etrade.com) is expired (as it most certainly
is
when viewewd with the Internet Options control panel!)
The exact calls that I make are:
schCred.dwVersion = SCHANNEL_CRED_VERSION;
schCred.grbitEnabledProtocols = SP_PROT_TLS1_CLIENT;
schCred.dwFlags = 0;
AcquireCredentialsHandle(NULL, UNISP_NAME, SECPKG_CRED_OUTBOUND, NULL,
&schCred, NULL, NULL, &creds, NULL);
This succeeds and I get a "valid" CredHandle back. I then do the
handshake:
SSPIFlags = ISC_REQ_SEQUENCE_DETECT | ISC_REQ_REPLAY_DETECT |
ISC_REQ_CONFIDENTIALITY | ISC_REQ_EXTENDED_ERROR |
ISC_REQ_ALLOCATE_MEMORY |
ISC_REQ_STREAM;
while (! connected) {
InitializeSecurityContext(creds, SSPIFlags, etc, etc)
}
Once I've connected, I retrieve the server certificate and display it:
QueryContextAttributes(ctxt, SECPKG_ATTR_REMOTE_CERT_CONTEXT,
&serverCert);
CryptUIDlgViewContext(CERT_STORE_CERTIFICATE_CONTEXT, serverCert, NULL,
NULL, 0, 0);
Now for some servers, such as us.etrade.com, the connection succeeds
(note
that I don't specify manual credential validation (and when I do, I get
the
same results)) and I'm able to send and receive data on the socket, but
according to that UI dialog, I don't truly have a trusted connection
because
the intermediate is expired. (For other sites, the connection succeeds
and
the dialog indicates that nothing at all is amiss.)
MSIE, Opera and FireFox all correctly display the "updated" intermediate
that seems to exist in the system store. I know FireFox uses its own
security engine, but MSIE seems to be making the same calls.
My thought is that I somehow need to get either AcquireCredentialsHandle
or
InitializeSecurityContext to refer to "some other" store where
intermediate
and root certificates may be found, but I've been searching for the
better
part of a week and I can't find any examples of how this might be done
(or
even if its the right thing to do.)
Can anyone shed any light on this? I've tried just about every
permutation
of parameters to AcquireCredentialsHandle and InitializeSecurityContext
without any luck.
Sample code available on request, and a free virtual pony if you can
help!
Thanks,
--sma
stevealgernon@xxxxxxxxx
.
- Follow-Ups:
- References:
- winsock + Schannel => Expired Intermediate Cert
- From: steve
- Re: winsock + Schannel => Expired Intermediate Cert
- From: Joe Kaplan
- winsock + Schannel => Expired Intermediate Cert
- Prev by Date: RE: Major problems with UAC
- Next by Date: Re: Major problems with UAC
- Previous by thread: Re: winsock + Schannel => Expired Intermediate Cert
- Next by thread: Re: winsock + Schannel => Expired Intermediate Cert
- Index(es):
Relevant Pages
|
|
