Article ID: 834438
Article Last Modified on 12/3/2007
APPLIES TO
- Microsoft Internet Information Services 6.0
- Microsoft Internet Information Services 5.0
- Microsoft Internet Information Server 4.0
SUMMARY
The previous VeriSign 128-bit International (Global) Server Intermediate certification authority certificate expired on January 7, 2004. This may cause problems for clients that try to establish server-authenticated secure socket layer (SSL) connections with Web servers and other SSL/Transport Layer Security (TLS)-enabled applications that do not have up-to-date certificates.
To prevent these problems, Microsoft Internet Information Services (IIS) operators should contact VeriSign to update the intermediate certification authority certificates for servers that use 128-bit SSL to connect to Web sites with the Secure Hypertext Transfer Protocol.
Impact
Clients cannot establish SSL-protected connections to Web servers that do not have updated certificates.
Recommendation
Install the updated version of the VeriSign intermediate certificate.
Affected software
- Microsoft Internet Information Server
- Microsoft Internet Security and Acceleration Server
- Microsoft Exchange
- Microsoft SQL Server
Technical details
Technical description
VeriSign maintains many certificates and certificate revocation lists (CRLs) that are expiring or that have expired. This is not uncommon. Typically, certificates and CRLs are short-lived by design. However, certificates are sometimes re-issued to give them a longer life span. This is generally not a problem, but it can create issues with servers that use secure socket layer (SSL) to help protect sessions that connect to their resources.
If a server operator installs an SSL certificate from VeriSign, together with the relevant issuing certification authority certificates, and then the server operator later renews the SSL certificate through VeriSign, the server operator must make sure that the intermediate issuing certificates are updated at the same time.
If you want to install the updated certificates, visit the following VeriSign Web site for the latest versions of these certificates and for the steps to install them:
Additional information
The validation of an X.509 certificate involves several phases. These phases include path discovery and path validation.
Path discovery is the process of determining if a certificate was issued by a valid entity. You can use many techniques to do this, including the following:
- Clients frequently maintain a cache of intermediate certificates. An intermediate certificate is a certificate that has proven useful in determining if a certificate was ultimately issued by a valid root certification authority.
Certificates may contain extensions that provide pointers to additional relevant information. One example of this type of extension is the Authoritative Information Access (AIA) extension. The AIA extension may contain a pointer to the certificate’s issuer.
Note Not all certificates contain this pointer, including the VeriSign certificates that are involved in this issue. Microsoft has been and will continue to be working actively with certificate issuers to encourage them to include this information in certificates that they issue in the future. For more information about this extension, see the Internet Engineering Task Force (IETF) Request for Comments (RFC) 3280.
- Servers can provide the additional information to the client. SSL is one example of this technique. In the SSL negotiation, the server provides the client with its own certificate and the certificates that the server has determined that the client can use to determine the server’s identity.
Path validation is the process of verifying the discovered path. Path validation involves the cryptographic verification of each signature on a certificate. Path validation also involves verifying that the issuer’s policies are enforced. Such policies include:
- Does the issuer believe that the certificate in question is still valid and is still under the control of the person it was originally issued to? This behavior is frequently referred to as “certificate revocation checking.” Windows supports a cryptographic object, a certificate revocation list (CRL), to perform this verification.
- Is the certificate being used for a purpose that the issuer intended it to be used for? For example, a certificate that was issued for e-mail should not be trusted to assert that a Web server is associated with a specific domain name (as is done in SSL).
- Are the certificates time-valid? Certificate life spans are constrained for security reasons. An issuer cannot certify that an individual or a resource has a particular identity for longer that the issuer is considered to be trusted.
Frequently asked questions
Is this a security vulnerability?
No. This is not a security vulnerability in any one of the affected products. The problem results only because of the expiration of a third party’s digital certificate.
What’s the scope of the problem?
Recently, VeriSign, Inc., a major certification authority, renewed their “VeriSign International Server CA - Class 3” certification authority with certificates that have a longer validity period. If Web server operators renewed their SSL certificates after this renewal, their customers may experience problems when they try to validate that their Web servers are actually associated with their organizations.
How is the issue resolved?
You can resolve this issue by manually updating the intermediate certification authority (CA) certificate on each Web server. To obtain this certificate, visit the following VeriSign Web site:
If this is a server issue, why do clients experience the problem?
The problem occurs when a client tries to establish a security-enhanced connection to a Web server. As a part of the process of establishing the connection, the server passes many certificates back to the client. The client uses these certificates to validate the server's certificate. In this case, one of the intermediate certificate authorities (the “VeriSign International Server CA - Class 3” CA) has expired. This intermediate certificate is not valid. Therefore, the browser displays a warning message to the user that explains that a security-enhanced connection could not be established.
Are Microsoft certificates involved?
No. These certificates are issued and are owned by VeriSign, Inc. VeriSign participates in a program that is maintained by Microsoft. In this program, third-party trust providers can help secure Internet commerce for Microsoft customers. For more information about this program, visit the following Microsoft Web site:
What certificate authorities participate in the Microsoft Root Program?
For a list of the current trusted third parties that have qualified for the Microsoft Root Program, visit the following Microsoft Web site:
Does Microsoft still update the certificates that Microsoft Internet Explorer uses?
Yes. As a part of the Microsoft Root Program, the list of trusted root authorities can be updated quarterly. For users of Microsoft Windows XP and Microsoft Windows Server 2003, this update occurs in the chain validation engine when it is presented with a certificate that it does not trust. When this behavior occurs, Windows Update is contacted to verify whether the certificate has been added to the Root Program. On pre-Windows XP clients, a recommended package is published to Windows Update for manual download. Microsoft recommends that enterprises make their own decisions about which trusted third parties they want users in their enterprises to trust.
Note Updates that the Microsoft Root Program provides will not address the issues that VeriSign Intermediate Certificate Expiration raises.
RESOLUTION
To resolve this issue, update the intermediate CA certificate store on each of your servers to the latest version of the VeriSign International Server Intermediate CA.
REFERENCES
For more information about how CryptoAPI builds certificate chains and validates revocation status, visit the following Microsoft Web site:
Support
For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:
Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
Security resources
For more information about security in Microsoft products, visit the following Microsoft TechNet Web site:
Disclaimer
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
Keywords: kbinfo KB834438
