digital securities solution (SSL) ::

known browser and application issues :

the following browser and third-party application problems have been recognized by VeriSign and documented below along with any solutions that are nown.

table of contents

Apache: IE5.x 56 bit versions are unable to connect to my Apache server when using a Secure Site Pro Certificate.

Browser connection issues with VeriSign Secure Site Server Pro ID's or Commerce SitePro Server ID's.

Time stamping service outage may have caused errors.

Internet Explorer 5.0 returns a failure to verify for all intended purposes error on a Global Server ID.

Netscape 6.0 "Could not verify this Certificate because of unknown problems.

Red Hat, running Secure Web Server Multiple SSL Issue.

Root CA Certificate Rollover.

SSL Certificate Validation Vulnerabilities with Internet Explorer.

Transporting an Existing Certificate from IIS 4.0 to IIS 5.0.

Netscape Browser version 6.0: Could not verify this Certificate because of unknown problems.

Apache: IE5.x 56 bit versions are unable to connect to my Apache server when using a Secure Site Pro Certificate.

Issue Description

IE5.x 56 bit versions are unable to connect to my Apache server when using a Secure Site Pro Certificate.

Resolution

Internet Explorer 56 bit versions (IE5.002919/20) contain a bug in their SSL implementation which causes the browser to fail when renegotiating (step-up) a 128 bit session with a Secure Site Pro. The following workarounds have been suggested:

Disable the 56bit SSL ciphers in your config file. This will force the browser to connect with a 40-bit session. DES-CBC-SHA, DES-CBC-MD5, EDH-RSA-DES-CBC-SHA, EDH-DSS-DES-CBC-SHA.

If you are using OpenSSL 0.9.5, you can try downgrading to 0.9.4, which has better support for SGC/Step-up.

This issue can also be caused by the use of the HTTP1.1 protocol. It may be resolved by using the HTTP1.0 protocol instead. For further information go to the URL below:
http://www.modssl.org/docs/2.6/ssl_faq.html#io-ie.

Browser Connection Issues with VeriSign Secure Site Server Pro ID's or Commerce Site Pro Server ID's

1) Microsoft IIS Servers Running a Secure Site Server Pro ID or Commerce Site Pro Server ID

Issue Description

When connecting to a Web site that uses Microsoft IIS and VeriSign's Secure Site Server Pro ID or Commerce Site Pro Server ID, export versions of Netscape Communicator 4.7x (56-bit encryption) may crash or fail to connect to the Web site, and display a "memory access violation" error.

Solutions

Netscape and VeriSign have analyzed the problem and determined that Microsoft IIS is not within the constraints of the SSL3 protocol specification during the "step-up" handshake by sending an SSL record to Communicator that is too short, causing Communicator to crash.

The best solution is for users of Netscape Communicator 4.7x to upgrade to a 128-bit version of Netscape Communicator.

There is also a fix that enables the export version of Netscape Communicator to connect to Web sites equipped with a Secure Site Server Pro ID or Commerce Site Pro Server ID and "step-up" to 128-bit encryption. You must disable SSL 3 in Netscape Communicator. To do this, please follow these instructions:

1. In Netscape Communicator, select Tools and then Security Info.
2. In the resulting Web page, click the Navigator link in the left column and then select Configure SSL 3 from the right pane.
3. In the subsequent pop-up menu, remove the check marks from the following two options:
. "RC4 encryption with a 56-bit key and a SHA-1 MAC" and
. "DES encryption in CBC mode with a 56-bit key and a SHA-1 MAC".

4. Click OK twice to finish.
VeriSign has called the problem to Microsoft's attention. Microsoft has stated that a fix is in development and may be addressed with the latest service pack. Customers that have re-installed their service pack have reported that the connection with these browsers worked. Other customers have successfully addressed the issue by downgrading to SP 5. (Note that these are not official workarounds to the problem.)

Microsoft offers a Hotfix to address this issue. It is important to verify that ONLY Netscape 4.7x 56-bit browsers are unable to connect. Problems can occur if the Hotfix is applied and the connection problem is not limited to Netscape 56-bit browsers.

Please refer to the following URLs to access the Hotfix:

a. Microsoft IIS 4.0:
SGC Connections May Fail from Domestic Clients
<<http://support.microsoft.com/support/kb/articles/Q249/8/63.asp>>

b. Microsoft IIS 5.0 (Windows 2000) running Service Pack 1:
Netscape Users Cannot Access Web Pages with 128-Bit Certificate Authentication
<<http://support.microsoft.com/support/kb/articles/Q260/2/66.ASP?LN=EN-US&SD=gn&FR=0Q260266>>

Note that the problem with Netscape 56-Bit browsers connected to a Secure Site Server Pro ID or Commerce Site Pro Server ID installed on IIS 5.0 only occurs with Service Pack 6A.

You may also address the issue by replacing your Secure Site Server Pro ID or Commerce Site Pro Server ID for a Secure Server SSL ID. If you wish to replace your Secure Site Server Pro ID or Commerce Site Pro Server ID for a Secure Server ID, call VeriSign Technical Support (650) 426-3400 for instructions.

For more information

For more information on this issue, we recommend that you contact Microsoft's technical support. For Microsoft's support information, you can visit: http://support.microsoft.com/directory/overview.asp?FR=0

2) Microsoft Internet Explorer 4 and 5 and Secure Site Server Pro ID's or Commerce Site Pro Server ID's

Issue Description

When users access a secure page on a site equipped with a Secure Site Server Pro ID or Commerce Site Pro Server ID, they will encounter one of the following error messages if the URL in the browser does not match the common name specific to the Secure Site Server Pro ID or Commerce Site Pro Server ID:

a) "Page not displayed"
b) "The certificate is invalid"
c) "The supplied certificate is invalid"

Solution/For More Information

Microsoft provides several documents that review this issue and suggest solutions. Please refer to these URLs:
http://support.microsoft.com/support/kb/articles/Q239/4/49.ASP?LNG=ENG&SA=ALLKB&FR=0
http://support.microsoft.com/support/kb/articles/Q244/3/02.ASP

Time stamping service outage may have caused errors.

Issue Description

Why do I get the following message when I try and download a file from a web site. "Signing certificates starting or ending time is outside one of its issuer's starting or ending time"

Solutions

VeriSign, Inc. had a timestamp service outage from 9 am on 02/23/2001 to 9 pm on 02/26/2001. Code timestamped during this timeframe might not download as desired on certain IE browsers versions. Solution would be to request the software distributors to re-timestamp and host the signed code again at their website.

Internet Explorer 5.0 returns a failure to verify for all intended purposes error on a Global Server ID.

Issue Description

VeriSign and Microsoft have determined that there is a slight user interface error between IE 5.0 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.

Issue Solution

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.0 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 contents of the certificate and verify the strength of the communication session. When a user clicks on the padlock icon in IE5.0 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 IE5.0 not recognizing a specific object ID (OID) describing the contents 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.

Nevertheless, Microsoft and VeriSign take this user interface error seriously, and are taking steps to correct the situation. VeriSign also recommends the display of the Secure Site Seal on the web page as a means of validity as this issue is being resolved.

Red Hat, running Secure Web Server Multiple SSL Issue

Issue Description

Red Hat: Secure Web Server 3.2 did not start properly when multiple SSL-enabled virtual hosts were configured.

Solution:

Red Hat has acknowledged this bug and has provided the following documentation and fix available at:
http://www.redhat.com/support/errata/RHBA-2000020-04.html

Instruct Users to Upgrade Their Browsers for Root CA Certificate Rollover

January 1, 2000

Netscape Communicator version 4.05 or earlier, Microsoft Internet Explorer 4.01 for Macintosh, and Microsoft Internet Explorer 4.5 for Macintosh include a root CA certificate that expired at the end of 1999.

Users of these browsers may be experiencing an additional dialog box when connecting securely with your site after January 1, 2000:

Users who choose to continue will establish an authenticated and encrypted SSL session. If you are using a 128-bit Secure Site Server Pro ID or Commerce Site Pro Server ID at your site, please see instructions below.

Based on recent market studies, VeriSign estimates that less than 4 percent of all browser users are affected by root CA certificate expiration, although the percentage of users of your site who are affected may vary. Users of Netscape Communicator 4.06 and later and of all versions of Microsoft Internet Explorer other than 4.01 for Macintosh and 4.5 for Macintosh are not affected by this issue. (Note: a bug in Internet Explorer 4.5 for Macintosh affects users' experience of secured Web pages.

We encourage Webmasters to help users of these browser versions upgrade their browsers as soon as possible.

What You Need to Do:

Help your users upgrade their browsers.
If you use a VeriSign Secure Site Server Pro ID or Commerce Site Pro Server ID, an EDI Server ID on your site, or are a Server ID for Web Trust customer:

Encourage your users to upgrade to the latest version of Netscape Communicator or to use Microsoft Internet Explorer. Link your Netscape users to <<home.netscape.com/computing/download/>> to upgrade.

Netscape Communicator 4.7 is also available on a $5.95 CD to users with slower modem connections. <<Click here http://cd.netscape.com/4.7/>>.

You should also instruct users of Internet Explorer 4.01 for Macintosh and 4.5 for Macintosh to upgrade to Internet Explorer 4.51 or later: link users to http://www.microsoft.com/mac/download/en/other_EN.asp. Users of both Internet Explorer 4.01 for Macintosh and 4.5 for Macintosh should also visit http://www.microsoft.com/mac/iesecissue as soon as possible for important information from Microsoft regarding further steps that will address security issues for Macintosh Internet Explorer 4.5 browsers.

If you accessed this page for root CA certificate rollover instructions prior to October 25, 1999, send an E-mail to our Root Rollover Specialist at CA-rollover@verisign.com or call 650-426-3400 for more information and instructions.

Users who choose to click "Continue" will establish an authenticated and encrypted SSL session.

Here is some sample language you may wish to post on your site for users of Netscape 4.05 or earlier who have not upgraded their browsers:

"Did you encounter a dialog box stating 'Certificate Authority Is Expired' when you tried to access one of our secure pages? Simply click Continue: the SSL session that secures your transaction with our site is not affected. You can avoid the dialog box in the future by upgrading your browser."

If you are using a 128-bit Secure Site Server Pro ID or Commerce Site Pro Server ID at your site, please see instructions below.

Secure Site Server Pro ID or Commerce Site Pro Server ID Users: Important Information for Sites That Wish to Ensure That All Site Transactions Occur in 128-Bit SSL Sessions

When users of export versions of Netscape 4.05 and later access pages secured by 128-bit Secure Site Server Pro ID or Commerce Site Pro Server ID, they can click "Continue" in the dialog box to continue their transaction in a 128-bit SSL session. However, when users of export versions of Netscape Communicator 4.04 and earlier access a page secured by a 128-bit Secure Site Server Pro ID or Commerce Site Pro Server ID and click "Continue" to bypass the dialog box, their browsers will connect securely, but in a 40-bit SSL session rather than in a 128-bit session. Some sites that use 128-bit Secure Site Server Pro ID's or Commerce Site Pro Server ID's require that transactions take place in 128-bit sessions and so will prevent users of Netscape Communicator 4.04 and earlier from accessing secured pages.

Therefore, it is vital that you instruct users of export versions of Netscape Communicator browsers version 4.05 and earlier to upgrade immediately.

If you wish to provide access to secure pages at 128-bit SSL only, we recommend that you block access to your pages by Netscape Communicator 4.04 and earlier. You may also wish to implement the following tools on your site.

Post Upgrade Tools on Your Site:

We strongly encourage you to use the following tools on your Web site to help users of Netscape Communicator 4.05 or earlier upgrade their browsers and avoid the root CA certificate expiration dialog box.

The Browser Security Update Tool opens a new browser window and automatically checks the security status of your visitors' browsers, offering upgrade instructions. The Tool helps browser users download the newest version of Netscape's browser.

Click here to download the Browser Security Update tool to run on your site.
<<http://www.verisign.com/server/cus/rootcert/vs_update_package.tar>>

The Browser Upgrade Button is similar to the Browser Security Upgrade Tool. However, this version does not automatically open a new browser window. Instead, it produces an "Upgrade Your Browser" button if, and only if, it detects an affected Netscape browser. The tool and instructions for installing the Browser Upgrade Button are included with the Browser Security Upgrade tool.

For 128-Bit Secure Site Server Pro ID or Commerce Site Pro Server ID: A Plug-in for Microsoft IIS and Netscape Enterprise server software that will help direct your customers who are unable to achieve 128-bit SSL to upgrade their browsers.

Click here to download the plug-in to run on your site for Netscape Enterprise running on Solaris. <<http://www.verisign.com/server/cus/rootcert/check128_v1_0_0_sparc.tar>>

Click here to download the plug-in to run on your site for Microsoft IIS running on Windows NT. <<http://www.verisign.com/server/cus/rootcert/check128_v1_0_0_winnt.zip>>

Update instructions on Security Center at Netscape Netcenter help users update or upgrade their browsers.

Click here to see the Security Center Update Instructions your users will experience, and get the URL to link to from your site. <<http://verisign.netscape.com/security/rootcert/>>

FAQs on Root CA Certificate Rollover <<http://www.verisign.com/server/cus/rootcert/faq.html>>

More Information on Root CA Certificate Rollover
<<http://www.verisign.com/server/cus/rootcert/facts.html>>

Webmasters: Prepare Your Site for Y2K - and Beyond <<http://www.verisign.com/y2k/server/index.html>>

If you use Netscape Enterprise Server Software:

Netscape Enterprise Server users who do not use their server for server-to-server authentication should delete the root CA certificate named either "VeriSign/RSA Secure Server CA" or "Secure Server Certification Authority" immediately. If neither of these certificates appears in the "Manage Certificates" screen of your Enterprise Server's Administration Server, you do not need to do anything.

Deleting this root CA certificate from the server has no effect on a browser's ability to make SSL connections to the Web server. If you use other Web server software, please check with your Web server software manufacturer for further instructions.

Netscape Server users who are using a Netscape server for server-to-server communication, and users of Netscape Proxy Server:
Click here for instructions. <<http://www.iplanet.com/cert/prodprep.html>>

Patch Available for “SSL Certificate Validation" Vulnerabilities

Originally posted: June 05, 2000 C/O Microsoft Corporation: http://support.microsoft.com Summary Microsoft has released a patch that eliminates two security vulnerabilities in Microsoft® Internet Explorer. The vulnerabilities involve how IE handles digital certificates; under a very daunting set of circumstances, they could allow a malicious web site operator to pose as a trusted web site.

In addition to eliminating the "SSL Certificate Validation" vulnerabilities, this patch also eliminates all vulnerabilities discussed in Microsoft Security Bulletin
<<MS00-033 http://www.microsoft.com/technet/security/bulletin/MS00-033.asp>>.

Frequently asked questions regarding this vulnerability and the patch can be found at http://www.microsoft.com/technet/security/bulletin/fq00-039.asp Issue Two vulnerabilities have been identified in the way IE handles digital certificates:

When a connection to a secure server is made via either an image or a frame, IE only verifies that the server’s SSL certificate was issued by a trusted root – it does not verify the server name or the expiration date. When a connection is made via any other means, all expected validation is performed.

Even if the initial validation is made correctly, IE does not re-validate the certificate if a new SSL session is established with the same server during the same IE session.

The circumstances under which these vulnerabilities could be exploited are fairly restricted. In both cases, it is likely that the attacker would need to either carry out DNS cache poisoning or physically replace the server in order to successfully carry out an attack via this vulnerability. The timing would be especially crucial in the second case, as the malicious user would need to poison the cache or replace the machine during the interregnum between the two SSL sessions. Affected Software Versions

. Microsoft Internet Explorer 4.0
. Microsoft Internet Explorer 4.01
. Microsoft Internet Explorer 5.0
. Microsoft Internet Explorer 5.01

Patch Availability
. http://www.microsoft.com/windows/ie/download/critical/patch7.html

Note: This patch also eliminates all vulnerabilities discussed in Microsoft Security Bulletin <<MS00-033 http://www.microsoft.com/technet/security/bulletin/MS00-033.asp>>.

Note: The patch requires <<IE 5.01 http://www.microsoft.com/windows/ie/download/ie501.html>> to install; a version that supports IE 4.01 Service Pack 2 will be released shortly. Customers who install this patch on versions other than these may receive a message reading "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q254902.

Note Additional security patches are available at the
<<Microsoft Download Center http://www.microsoft.com/downloads/search.asp?
Search=Keyword&Value='security_patch'&OpSysID=1>>.

More Information

Please see the following references for more information related to this issue.
. Frequently Asked Questions: Microsoft Security Bulletin MS00-039,
http://www.microsoft.com/technet/security/bulletin/fq00-039.asp

. Microsoft Knowledge Base article Q254902 discusses this issue and will be available soon.

. Microsoft TechNet Security web site, http://www.microsoft.com/technet/security/default.asp

Obtaining Support on this Issue

This is a fully supported patch. Information on contacting Microsoft Technical Support is available at http://support.microsoft.com/support/contact/default.asp .

Transporting an existing certificate from IIS 4.0 to IIS 5.0

Issue Description

Upon renewal of an existing certificate created in IIS 4.0 and transported to IIS 5.0, a bad CSR will be created. This can be attributed to the fact that a CSR generated in IIS 4.0 is smaller in size than it's counterpart in IIS 5.0

Common Errors: Error #10d

Solutions

Since the underlying factor resides in the fact that there is a CSR size discrepancy, you must create a new key in lieu of creating a renewal request

Netscape Browser version 6.0: Could not verify this Certificate because of unknown problems".

Issue Description

On a Netscape browser, version 6.0, you may receive the error "Could not verify this Certificate because of unknown problems".

Resolution

The following instructions will show you how to disable TLS in each browser. VeriSign realizes that this solution is less than ideal, as you may not have control of each browser that connects to your site. It may be possible to disable TLS in your server software to prevent this issue. At this time VeriSign does not have any information on how to do this, but will update our knowledge base as information becomes available.

If "enable TLS" is disabled, the browser connects properly to the site.

Instructions for disabling TLS (in the browser do the following):
1. Go to TASKS from the menu
2. Privacy and security
3. Security Manager
4. Once in the security manager:
5. Advanced
6. Options
7. remove the check mark next to "Enable TLS"
8. the default is enabled
9. The browser may need to be restarted