390835 - usa.canon.com - Intermediate Certificate Missing

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3 Mnenhy/0.7.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3

Very recently I bought a Canon digital camera.  Among the instructions,
there was a one-page notice about registering the camera online.

I went to the indicated URL
<http://www.powershot.conm/productregistration>, which redirected me to
<http://www.usa.canon.com/consumer/controller?act=OnlineRegIndexAct>.
After indicating the product, series, and model number, I selected the
Go button.  I immediately got a warning popup "Website Certified by an
Unknown Authority".  The same warning appeared if I went to the "Contact
Canon" page and tried to send them feedback on their Web site (see below).

A little research indicated to me that they have a SSL site certificate
signed by an intermediate certificate from VeriSign (VeriSign Class 3
Secure Server CA).  While SeaMonkey has all the root certificates from
VeriSign, intermediate certificates are supposed to be installed on the
server for the secure Web site and not in the browser.

Accepting the secure connection for the Web site feedback (for that one
session only), I communicated this problem to Canon.  Their response was
 that I should use Internet Explorer.

I understand that IE will indeed compensate for this error by searching
for and accessing the intermediate certificate.  However, that is merely
enabling an invalid, sloppy implementation of a secure server.

I responded to Canon that they should contact VeriSign to learn how to
configure their server to include the intermediate certificate.


Reproducible: Always

Steps to Reproduce:
1.  Go to <http://www.usa.canon.com/consumer/controller?act=ContactCanonAct>.  
2.  Select "Click here" under "Site Feedback".  
Actual Results:  
Warning popup "Website Certified by an Unknown Authority" appears.  Requires user action to accept secure connection with dubious site certificate.  

Expected Results:  
Secure connection is established without user action.  

The "Steps to Reproduce" are an alternative to the steps in "Details".  This is a server problem at Canon and not a problem with only one Web page.  Since Canon asserts that I should access their site via Internet Explorer (which compensates for this server configuration error), Canon does not seem motivated to fix the problem.

Comment 1

[Bob Clary [:bc] (inactive)]

Nelson, I thought that this was definitely an evangelism issue until I saw some of your posts related to NSS 3.12. Is this something that is broken in Gecko 1.8 and earlier and will work in the future with NSS 3.12 or is the approach Canon is taking completely wrong and we should try to educate them?

Comment 2

[David E. Ross]

Canon is using a site certificate signed by an intermediate certificate owned by VeriSign.  VeriSign states (at <http://www.verisign.com/support/verisign-intermediate-ca/index.html>):  
"As of April 2006, all SSL certificates issued by VeriSign require the installation of an Intermediate CA Certificate.  The SSL certificates are signed by an Intermediate CA using a two-tier hierarchy (also known as trust chain) which enhances the security of your SSL Certificate. If the proper Intermediate CA is not installed on the server, your customers will see browser errors and may choose not to proceed further and close their browser."

Thus, Canon is not following the instructions provided by the certificate authority from which Canon obtained its site certificate.  

The fact the IE will fetch the needed intermediate certificate -- allowing a secure server to operate while improperly configured -- might actually be a security vulnerability.  (I'll have to think about this a while before I'm sure.)  

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

It is absolutely an evangelism issue.
The SSL & TLS RFCs REQUIRE all servers to send complete chains.

It is true that the standards for certs (a separate set of RFCs)
are evolving to allow relying parties to fetch missing intermediate
CA certs.  But that does not remove the requirement on TLS servers
from the TLS RFCs.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The URL to reproduce this is 
https://www.usa.canon.com/consumer/controller?act=FeedbackFormAct
    ^
The TLS RFC is RFC 2246.  
SSL 3.0 is only an internet draft, never got to RFC.

There is no requirement that clients must ever fetch certs.
They MAY but are not required to do so, any many small clients 
(PDAs) will nevr do so.  That is why the TLS RFC requires TLS 
servers to send complete cert chains, up to (and optionally 
including) the root CA cert.  

But most sysops just test with IE, and when it appears to work
with IE, they stop and assume they have fulfilled the requirements.

Comment 5

[David E. Ross]

I rarely use IE, and I have no knowledge of its inner workings.  Therefore, I have no insight into how it handles missing intermediate certificates.  

The question is whether IE will fetch only missing intermediate certificates or also fetch missing root certificates.  If the latter, this is definitely a security vulnerability that Mozilla should not emulate.  This could easily result in a bogus banking Web site authenticating as legitimate, using an equally bogus root certificate.  

There is also the question of how a chain of intermediate certificates would be handled.  See bug #376853 regarding a chain in the form [root>intermediate>intermediate>site].  As I recall, I wrote that bug report after I discovered that the first intermediate certificate in the chain was missing from the site's server.  With even longer chains, I would be very concerned about security vulnerabilities if missing intermediate certificates were fetched by the browser.  

This is one reason why I only use IE to check the layout of my own Web pages and to download Windows patches.  

Comment 6

[Julien Pierre]

David,

Fetching certs in itself is not a vulnerability. Trusting them would be. Even if IE fetches certs in the chain up to and including the root, it should never automatically trust the root cert it downloaded. It would render PKI pretty useless if it did - everything would always be trusted. The fact that security errors and cert mismatches still exist in IE pretty much prove that this is not the case , fortunately ;).

Comment 7

[bill]

Which build (if any) of FireFox supports downloading the AIA Extension "CA Issuers" to construct valid cert paths?  I've noticed that VeriSign's been adding this extension for a while and -- despite years of education -- my administrators frequently forget to add the intermediate CA certificate into their application.

I'd like to start issuing end entity certificates with this extension to make this problem go away. I know IE will support it, am looking to determine if this is already supported on the roadmap for FireFox.

Comment 8

[Eddy Nigg (StartCom)]

It's the CA Issuers directive in the AIA extension. Does this help? I'm not aware that any build supports automatic fetching yet. Nelson, do you have any more details?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Hi Bill, 
NSS 3.12, the version in Firefox 3, has two separate implementations of 
the cert chain building and validation algorithm, the old implementation and 
a brand new one that includes AIA support and numerous other new features.
Firefox uses the new algorithm only when checking a cert to see if it is a 
valid EV cert, which happens AFTER it has previously checked the cert to see
if it is a valid ordinary SSL server cert.  That previous check uses the old
code, which does not do AIA.  When the browser gets an incomplete cert chain,
the first test generally fails (since the intermediate CA cert is missing).
The second check might pass (because of AIA) but the browser doesn't do it,
since an EV cert must be a valid SSL cert first.  So, today, the AIA fetching
capability in NSS 3.12 is effectively unused by Firefox 3.

Some day, Firefox 3 will use the new code for both checks, the first and
the second, and when that happens, Firefox 3 should then be taking full 
advantage of AIA cert fetching.  

Firefox 3 saves intermediate CA certs that it has validated.  This means
that if FF3 has previously visited some server that sent a complete cert
chain, and then subsequently visits a server with an incomplete cert chain,
whose (missing) intermediate CA cert is one previously seen (and stored) 
by FF3, then FF3 will be able to complete the chain using the previously
stored CA cert.  So, the problem is mitigated somewhat by the order in 
which users visit different servers, assuming that SOME servers get it right.

You might also suggest to your server developers that they make the servers
check their own chains for completeness at startup, and complain if they 
are incomplete.  That should help a lot.  

Finally, there is a way to force the browser (or any app using NSS 3.12) to
use the new cert validation code for all validations.  It is done by setting
an environment variable.  This is hardly a practical solution for your users,
of course, but it might enable you to test and see if there are any issues 
related to AIA before FF3 rolls that feature out.  
Set NSS_ENABLE_PKIX_VERIFY=1 before starting the browser to force that.

Comment 10

[bill]

Thanks, Nelson. This explanation helps a lot. My forehead and pager are getting sore from my administrators failing to properly configure their SSL applications. I noticed that another Popular CA Around The Block is using this directive in their SSL certificates so I'm building a compatibility matrix before we start testing against our demographics.

Just to be clear: Will this new feature support fetching intermediates for both non-EV and non EV certificates?

I'd prefer it if NSS supported both types of SSL certs (all certs, for that matter) ... in case this is still open for discussion. :)

Comment 11

[David E. Ross]

I find that the failure to install intermediate certificates on a secure server to be annoying, which is why I submitted this bug report in the first place.  However, I am more concerned about what such a failure indicates --  very sloppy attention to necessary details regarding the operation of a secure Web site.  What else has the server administrator done incorrectly or failed to do?  

Verisign is not the only CA that signs site certificates with intermediate certificates.  Indeed, this is now the usual and recommended practice.  Verisign tells both users and the public that the intermediate certificate MUST be installed on the server with the site certificate.  If a server administrator ignores this requirement, we should all be concerned regarding the general security of the affected Web site.  

Thus, I do not agree that a failed server chain should ever be bypassed as indicated in Nelson's second paragraph (comment #9).

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #10)

> Just to be clear: Will this new feature support fetching intermediates 
> for both non-EV and non EV certificates?

It will if it is used for both, yes.  Please Try the environment variable 
with your own FF3 browser and see how it works.

Comment 13

[Eddy Nigg (StartCom)]

Nelson, not only doesn't it work (on latest 3.1b2), but I discovered a weird bug. Every time I hit "Get Certificate" I receive the popup warning and can't view the certificate nor add an exception. It doesn't happen when NSS_ENABLE_PKIX_VERIFY=1 isn't exported. Screenshot will follow.

Comment 14

[Eddy Nigg (StartCom)]

Attachment: Possible bug with NSS_ENABLE_PKIX_VERIFY=1

export NSS_ENABLE_PKIX_VERIFY=1 prior to executing FF3.1b2 results in this popup warning when clicking on "Get Certificate". It's impossible to add an exception in case the intermediate CA is missing and the NSS library doesn't fetch the intermediate CA certificate.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Yeah, my mistake.  Sorry  Fetching of certs via URLs in AIA extensions is an 
optional feature of the new code, and that option is not turned on by the 
environment variable.  When the environment variable is set, the new code is
supposed to emulate the feature set and capabilities of the old code.  
I had forgotten that.  Sorry.  

Use of this environment variable is not a supported feature of FF3, so bugs on 
it would not be accepted.  It's purely an experimental feature at this time.

Comment 16

[bill]

I'm using FF 3.6 and was testing compatibility for the CA Issuers extension. Sadly, it looks like this feature is still not enabled by default within this browser.

What's the next step to propose changing the default behavior?

Comment 17

[Chris Lawson (gone)]

(In reply to comment #16)

> What's the next step to propose changing the default behavior?

Probably filing a bug somewhere other than Tech Evangelism, since this bug is *supposed* to be focused on getting Canon to fix their broken site. Somewhere around comment 7 is where this got WAY off track, and pretty much everything from there on down has nothing whatsoever to do with this specific TE bug.

However, based on comment 15, it doesn't sound like what you're looking for is going to be changed any time soon, if ever.

Comment 18

[bill]

Bug 542674 created to track this feature request properly.

Comment 19

[Matt Caywood]

There no longer seems to be a problem with Canon's site,
and the reproduction URLs no longer exist.

https://www.usa.canon.com/consumer/controller?act=FeedbackFormAct

RESOLVED-->FIXED. 

Further intermediate certificate discussion in Bug 542674, please.

Comment 20

[David E. Ross]

Yes, I was able to register my Canon digital camera -- some three years after I bought it.