In case anybody was interested, I have a resolution to the issue. The core problem resulted from moving the Certificate Services server several months back. The name of the server changed, and I had (mostly) gotten that configured correctly. What I didn't understand was that the CRL distribution point was embedded in already issued certificates and they were pointing to a no longer existing server. I got the CRL generation cleaned up and renewed the certificate, and that resolved the problem.
Much thanks to Steve and Michael for their help! Bill Mayo -----Original Message----- From: Steve Kradel [mailto:[email protected]] Sent: Monday, October 31, 2011 3:18 PM To: NT System Admin Issues Subject: Re: Speed up internal SSL? If you're running an ASP-based OCSP reponder (such as the one that comes with AD Certificate Services) it could definitely take a few seconds to spin up if the application's been recycled / unloaded from IIS due to infrequent use. You might try adjusting the application pool settings to keep it around longer / indefinitely. --Steve On Mon, Oct 31, 2011 at 1:51 PM, Mayo, Bill <[email protected]> wrote: > Thanks, again. I have some work to do here to try to see what I can see with > the tools that have been suggested. I did, however, note one thing and I > mention it in hope that it might mean something to somebody. The server in > question is running IIS 6 (WS2003). When I connect via SSL from IE6, there > is no significant delay. However, when I connect via SSL from IE8, there is > the aforementioned delay. It looks like OCSP stuff was added as of IE7. Is > there something additional that needs to be done in IIS6 to support that? > > Bill Mayo > > -----Original Message----- > From: Steve Kradel [mailto:[email protected]] > Sent: Monday, October 31, 2011 1:26 PM > To: NT System Admin Issues > Subject: Re: Speed up internal SSL? > > There is a learning curve to using the openssl tools, although it's > worthwhile if you wrestle with SSL often. s_client does attempt to > validate certs unless told not to. To wire up validation you'll need > to save the other certs in the chain as per here > <http://www.cyberciti.biz/faq/test-ssl-certificates-diagnosis-ssl-cert > ificate/> and > <http://monkey.org/openbsd/archive/tech/0308/msg00125.html>. > > I'll try to do some checking to see if the Windows CAPI can be told to > generate a non-overwhelming amount of cert validation info. > > In perspective, Michael Smith's suggestion to start with Fiddler / Netmon / > Wireshark is probably a more sensible place to begin if PKCS, PEM and DER are > unfamiliar acronyms. > > --Steve > > On Mon, Oct 31, 2011 at 12:42 PM, Mayo, Bill <[email protected]> wrote: >> Thanks for the response. I was not familiar with OpenSSL, but I have gotten >> that installed and am trying to do as you suggest. I was able to connect to >> the server using "openssl s_client -connect server.name:443" and see that it >> connected very quickly. Beyond that, I am having trouble figuring out the >> proper command(s) to do the validation on/off as you said. I see a "verify" >> option, but that looks like something that has to be run against an exported >> certificate, correct? >> >> Bill >> >> -----Original Message----- >> From: Steve Kradel [mailto:[email protected]] >> Sent: Monday, October 31, 2011 11:42 AM >> To: NT System Admin Issues >> Subject: Re: Speed up internal SSL? >> >> Five seconds is far too long for a (correctly configured) SSL negotiation >> and you are probably on-track to suspect slow processing of the CRL or OCSP >> bits of the certificate. >> >> I'd suggest testing it out with "openssl s_client", with certificate >> validation on and off. Also it would be helpful if you posted the >> X.509 cert details. >> >> --Steve >> >> On Mon, Oct 31, 2011 at 11:25 AM, Mayo, Bill <[email protected]> wrote: >>> I am not much of an IIS guy (know enough to get by), and I have a >>> request from one of our developers to investigate why SSL is slow. >>> What I can confirm is that the initial connection to SSL takes >>> several seconds (5 or more), but after that it is fine. My research >>> on the topic suggests that it is normal for the initial connection >>> to be relatively slow, but it seems like it shouldn't take as long >>> as it does. The one thing I ran across that I am not clear whether >>> may be at issue is the certificate revocation checks. The >>> connections in question are certificates that are for internal web >>> access and are signed by our internal certification authority (domain >>> controller). >>> Is there something I can do in regards to certificate revocation checks to >>> speed the process up? Any other suggestions? >>> >>> >>> >>> ~~~~~~~~~~ >>> >>> Bill Mayo > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
