706155 - anvente.com does not send Intermediate CA cert when the client (Firefox) includes the SNI extension

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Terry R.]

Complaint from website owner:  I have a website that has been up since 1997, is ssl secured and is tested every month for that security.  Up until today I had no issues but now I have customers calling in that the site is popping up with a "get me out of here" message.  I am losing customers hourly!!!!  What is going on!!! it does not do this in any other browser and all certificates are in place.

www.anvente.com

Steps to reproduce:
1.  In Firefox 8, go to site above.  Click on any category under "Main Categories"
2.  Select any item by clicking the "Add to Cart" button.
3.  Click "Checkout" ("Continue" on further attempts)
4.  On Login screen, under Register, click link, "Start Express Checkout"
5.  Fill out info
6.  Click "Get Shipping Rates" button.
7.  Click "Continue" button.
8.  This Connection is Untrusted

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: Screen shot of cert heirarchy 10.0a2 OSX

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

works for me on Aurora 10.0a2 on OSX
Fails for me on Aurora 10.0a2 on Win7 & Firefox 8 on Win7

Windows 7 64bit with Firefox 8 & 10.0a2 have the error

Technical Details:
www.anvente.com uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Certificate Information:
Certificate "www.anvente.com"
Subject: C=US,OU=Domain Control Validated,O=www.anvente.com,CN=www.anvente.com
Issuer: C=BE,OU=Domain Validation CA,O=GlobalSign nv-sa,CN=GlobalSign Domain Validation CA
Validity: from 2011-01-31 14:12:45 UTC to 2012-02-01 14:12:43 UTC

Certificate Viewer shows different hierarchies.
10.0a2 (OSX) (screen shot attached)
8.0/10.0a2 (Win)  only shows the www.anvente.com line and none of the check marks

This appears to be Windows specific

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

WFM on Windows nightly.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

And fails for me on 8.0.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

CCing some PSM types.

Comment 6

[Daniel Veditz [:dveditz]]

Do you have multiple servers (to handle load) and if so is it possible one of them is not sending the correct intermediates? The site looks OK, some problems but nothing that should prevent Firefox from connecting
https://www.ssllabs.com/ssldb/analyze.html?d=www.anvente.com

The error code is very specific, "no issuer chain was provided". That means the server is sending only the site certificate but not the intermediates. In those cases it might work for some people if they've visited another site with a GlobalSign-issued certificate first: the intermediate will be found in the memory cache. The site will also still work for IE users since Microsoft supports the "AIA" extension found in the certificate. But users of other browser who haven't visited a GlobalSign-issued site first will get this error.

But ATM it appears your site is, in fact, sending the intermediates (see the SSLLabs report above: "Chain Length 2; Chain issues None"). Mysterious.

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

It is failing for me on nightly on windows

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I tested in my regular profile, so it's possible that I visited a site that provided the rest of the issuer change already.

Comment 9

[Kai Engert [:KaiE:]]

I can reproduce this problem using all versions from Firefox 3.6.x to FF 10.

The problem isn't dependent on the FF version, but rather, the problem occurs when visiting this site using a fresh user profile, for the first time.

I initially thought the server might be misconfigured - but it appears the server is sending the correct intermediate.

I don't have a good idea yet, need to investigate more.

For testing purposes, I manually imported the intermedia CA that was sent by the server into cert manager authorities (WITHOUT adding trust), and that makes the site work.

But this shouldn't be necessary, this should happen automatically - as we do all the time.

https://www.anvente.com
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Comment 10

[Kai Engert [:KaiE:]]

Ok, after several hours trying to analyze what's going on...

Sometimes the server sends only the server certificate, sometimes it's sending the cert, too. This seems to depend on the application connecting to the server.

(a) When using Firefox directly:
  I always see ONLY the server certificate
  The libSSL function ssl3_HandleCertificate gets only about 1273 bytes.

(b) When using Firefox to connect through a debugging tool such as ssltap:
  We receive both server and intermediate certificates.
  The libSSL function ssl3_HandleCertificate gets about 2420 bytes.

(c) When using "openssl s_client -showcerts -connect"
  The server sends both server and intermediate certificates.


Apparently the server behaves differently based on variations in the TLS handshake data sent by the client.


I learned about this difference by using the "ssldump" tool, which inspects the packets on the network interface. (-ANX -d)

I can clearly see that for (a) we only receive the strings contained in the server cert.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I am assigning this to Kai since he seems to be working on it. Kai, if you stop working on it, please unassign.

Is it possible that this server returns different cert chains in any of these situations?:

* if SNI is disabled vs enabled
* If SSL2 and/or SSL2 compatible hello is enabled
* If SSL3 only is enabled
* If TLS1 only is enabled

My initial suspicion is that there is a default certificate configuration that is used when the SNI is not included in the client hello, and another configuration used when SNI is included in the client hello.

Comment 12

[Kai Engert [:KaiE:]]

(In reply to Brian Smith (:bsmith) from comment #11)
> 
> My initial suspicion is that there is a default certificate configuration
> that is used when the SNI is not included in the client hello, and another
> configuration used when SNI is included in the client hello.

Your guess was correct.

When sending the TLS SNI extension, the server returns only a single certificate.

Compare the output of
openssl s_client -showcerts -servername www.anvente.com -connect www.anvente.com:443
and
openssl s_client -showcerts -connect www.anvente.com:443

I think this bug is invalid.
The server is misbehaving.

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Terry, are you able to contact the website owner? If so, could you explain that this is due to a configuration error on the server, that occurs when the Server Name Indication (SNI) TLS extension is sent by the client. The website administrator needs to make sure that the same SSL certificate configuration is used in the default configuration and in the per-domain-name configuration.

It works in other browsers partially because they implement the AIA intermediate certificate fetching mechanism. We (Firefox/Gecko) do not implement that and don't have immediate plans to do so, though we may get around to doing so eventually.

Comment 14

[Terry R.]

Brian, I sent the website owner the bug link when I filed it.  I will send him another email to have him read through the comments.

Comment 15

[Karl Dubost💡 :karlcow]

This is now redirected to http://weddingflowersandmore.com/
which doesn't exhibit the issue.