- Internet Explorer 5.X returns a failure to verify for all intended purposes error on a Global Server Certificate?
When viewing a certificate in IE 5.X it can return a failure to verify for all intended purposes error when connecting to a secure page.
VeriSign and Microsoft have determined that there is a slight user interface error between IE 5.X and VeriSign Global Server IDs. However, this error DOES NOT affect the basic functionality or security of the two products. Furthermore, the user interface implications should be invisible to most users. The following Microsoft article details this error and lists the browser versions affected:
Click here to link to Microsoft support
VeriSign Global Server IDs are intended to enable 128 bit strong encryption communication sessions between browsers (both import and export versions) and servers which have a Global Server ID. Users of Microsoft IE 5.X are, in fact, able to connect successfully to a server using a VeriSign Global Server ID, and will do so using strong encryption. 128 bit SSL is established automatically, with no special action needed on the part of end users.
In most SSL sessions, when a user clicks on the padlock icon in Internet Explorer, they are able to easily view the bodytexts of the certificate and verify the strength of the communication session. When a user clicks on the padlock icon in IE 5.X when connecting to a site using a Global Server ID, they may see a message that says "This certificate has failed to verify for all of its intended purposes."
This error is due to IE 5.X not recognizing a specific object ID (OID) describing the bodytexts of the certificate. However, the effect is limited to one of user interface. The user will, in fact, connect at 128 bits. If fact, if the user clicks on the "Certificate Path" tab in the same dialog box, a dialog will show that the certificate indeed verifies and is trusted for all intended purposes.
VeriSign have now implemented a new intermediate certificate which can be downloaded and installed in your browser. The object IDs (OID) have been updated and the error message should now occur. If you are still experiencing difficulties please contact Microsoft support with any enquiries: http://support.microsoft.com
- Expired root certificates
When a particular browser connects with a Server ID, Secure Sockets Layer (SSL) functions automatically by checking if the Server ID is trustworthy, meaning the corresponding CA Root Certificate that signed the Server ID is present in the browser's trusted root library. Periodically, VeriSign creates roots to be used at a future time, and provides these updated roots to the browser manufacturers for inclusion in their next browser revision. Therefore, different versions of the Root CA Certificate could be installed in different versions of browser. This can potentially create situations where an older version browser still in use may not have the appropriate Root CA Certificates embedded in the Trusted Root Library that match the current CA Root Certificate that signs the Server ID for the site.
- How do I know if I'm affected by periodic root certificate expiration?
VeriSign's root certificates are present in 98% of the browsers available - more than any other CA in the world. However, every Root CA certificate is assigned a validity period such that the root will expire on some finite date to ensure that technologically, the best cryptography characteristics are used based on the available computing power at any given time. VeriSign works with the major browser supplier to embed these roots into each version of a browser as it evolves.
There are several conditions that must be met for SSL validation to occur with a given site.
a. The Root CA used to validate a given certificate must be valid and not expired.
b. Both the Intermediate CA and CA Root Certificate have validity periods and expiration dates and can only
be used in configurations where the subordinate certificate (Server ID or Intermediate CA) expires before the master
certificate (Intermediate CA and Root CA) (verify).
c. Only the Intermediate CA that was signed by the corresponding Root CA can be used to validate the Server ID also signed by that Root CA.
If any of these conditions are not satisfied, SSL validation will not occur and https:// access to the web site will not be possible.
If you are affected by a root expiration you will receive an error message such as "Cannot connect to an expired server certificate" or you may encounter a dialog box indicating that the root certificate has expired and prompting the user to check their computer's clock.
- What steps should I take to address periodic root certificate expiration?
It is recommended that you keep your browsers updated, as this will avoid any problems with periodic root expiration. Doing this will also give you the most up to date security features available from the browser supplier as well. Please note that Microsoft no longer supports either Internet Explorer version 4 or Windows 95. For a complete list of supported Microsoft products please visit: http://support.microsoft.com/default.aspx?scid=fh;en-us;complifeport
If you are experiencing problems because your root certificates have expired, you will need to either upgrade your browser or your root certificate to overcome this issue. IE 4.0 users should be encouraged to upgrade to IE 5.5 or higher or you can go to http://www.verisign.com/support/site/rootDoc.html
to manually install the new VeriSign Class 3 PCA Root (expiring in 2028) into your browser.
- Will root certificate expiration happen again?
Yes. VeriSign's root certificates are present in 98% of the browsers available, more than any other CA in the world. However, every Root CA certificate is assigned a validity period such that the root will expire on some finite date to ensure that technologically, the best cryptography characteristics are used based on the available computing power at any given time. VeriSign works with the major browser supplier to embed these roots into each version of a browser as it evolves.
- The error "No Common Encryption Algorithm"?
The error "No Common Encryption Algorithm" is generally caused by an incompatibility of signing algorithms between the server and the browser trying to connect to it. In March 2000, VeriSign started issuing server certificates with a signing algorithm of SHA1, which replaced the MD5 signing algorithm. This new signing algorithm has a higher level of security, and it is faster as well. SHA1 has been around since the late 1980's and is becoming the standard for certificates. All major browser and server vendors agreed to support this algorithm in the mid-1990's.
Resolution: Older browsers may not be able to connect to servers with certificates containing the SHA1 algorithm. If you are using Internet Explorer (IE) 4.01 or 4.5 for the Macintosh, you will receive this error, as these browsers do not support SHA1. In order to resolve this issue, you will need to upgrade to a browser that does support SHA1. All Mac IE browsers newer than 4.5 do support it. This error can also occur when a browser fails to negotiate a compatible encryption level with a secure server. If your server is configured to only allow 128-bit connections, all 40-bit browsers will not be able to connect to your site using SSL and the user will see the "No Common Encryption Algorithm" error. To fix this problem, you may disable the option to require 128-bit on the server, or upgrade to a Global Server Certificate. VeriSign Global Server IDs allow newer browsers to step-up to a stronger 128-bit connection, even if the browser is the 40-bit export version of the software. The above information is well documented on the VeriSign site, reference number "S1613".
- Renewing a server certificate the error "30e8" may be received ?
Background information
OU information: From year 2000, VeriSign includes the RPA (Relying Party Agreement) information in the certificate
as an additional OU (Organisational Unit). If an organisation's original enrolment for a certificate did not include the OU, the RPA replaced the blank OU. Upon renewal of the certificate, the CSR will not match what is in the VeriSign database. A new enrolment is required in order to correctly enter the appropriate information in the OU field. At this point, most common servers do not allow you to create a CSR without an OU.
Action
Generate a new CSR specifying an OU and enrol for a new certificate. Note that only a renewal price will be automatically charged as the organisation is already recognised. The OU is generally defined as a department name or server name and this field will appear in your certificate details. Please bear in mind a new certificate application is valid from the date of issuance. If you require a pre-determined date outside the normal 3-5 working days of issuance, e-mail order-support@trustwise.com with your requirement stating the application common name and issuance date.
Further information
Please review the RPA (Relying Party Agreement) for practice standards. The RPA is available at: https://www.verisign.com/repository/rpa.html. That's the OU = "www.verisign.com/CPS Incorp. by Ref., LIAB. LTD. (c) 97 VeriSign" you've seen in certificates. Note
that the OU is only added for Microsoft, Netscape, and Stronghold servers.
