Closed Bug 538342 Opened 15 years ago Closed 15 years ago

Firefox verifies but can't verify https://startssl.com/logon.ssl

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
3.5 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: david, Unassigned)

Details

When trying to load this page (to log in), firefox pauses for a while, then displays an error page indicating: "Secure Connection Failed An error occurred during a connection to www.startssl.com. * The page you are trying to view can not be shown because the authenticity of the received data could not be verified. ..." The only button action available is to try again. If you try to manually add an exception via the preferences, after entering the URL and [Get Certificate], firefox displays: "Valid Certificate This site provides a valid, verified identification. There is no need to add an exception." - Tested with a completely new profile - Tested with a new profile with a personal certificate installed for identity - Tried removing startcom certs to no avail. Firefox is unable to ignore built in obj. certs that you've requested to be deleted. I understand that StartCom transitioned to a new root CA. They're both listed. I've also re-installed ca-certificates package and verified there weren't any left over old certs. openssl client verifies the certificate correctly.
Eddy - startcom failing to negotiate an acceptable set of parameters? SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert)
Any progress on this Eddy? 'Tis impossible to use firefox (and konqueror) with startcom websites and it's bit of a PITA using opera.
This page can't be accessed in case no client certificate is installed into the browser. I don't know WHAT the browser actually sends, but whatever it is, it's not acceptable by the server and it attempts to connect nevertheless. In my opinion this is the wrong approach and obviously the error message isn't really helpful either. For comparison, MSIE shows the client certificate UI which in this case would be empty. At least in this case, the user might figure that he doesn't have is requested and probably less surprised that it doesn't work. Firefox instead simply connects and send I don't know what. The browser should not send anything IMO and not connect. At the moment we covered this in our FAQ: https://www.startssl.com/?app=25#10
I have a client certificate installed, both in Firefox and Opera. Even with the certificate, Firefox refuses to load https://www.startssl.com/logon.ssl. Opera will only load after it pops up the certificate UI, warning about your site certificate, and the inability to verify the chain of trust. The browser is attempting to connect because I -want- it to load that webpage, and I do have a certificate installed. I brought this up a year ago. The only time you can log in with Firefox is the very first time you visit and you create a new account with the wizard. As long as you keep that session fresh and don't log out, you can remain in the control panel as long as you want. Once you've logged out, Firefox and startssl.com can't negotiate a session. All browsers that I've tried all pop up warnings about failures to validate your certificate. A year ago you didn't exist in the Root CAs and we installed your CA cert locally on our computer. We can't do that now as your root certificate "already exists" with the Root CAs.
david@Scott ~ $ openssl s_client -connect www.startssl.com:443 CONNECTED(00000003) depth=1 /C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=IL/ST=HaDarom/L=Eilat/O=StartCom Ltd. (Start Commercial Limited)/OU=StartCom Extended Validation/CN=www.startssl.com/emailAddress=webmaster@startssl.com/serialNumber=513747303/2.5.4.15=V1.0, Clause 5.(b)/1.3.6.1.4.1.311.60.2.1.3=IL i:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA 1 s:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIIsTCCB5mgAwIBAgICAJYwDQYJKoZIhvcNAQEFBQAwgYExCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0 [...] G5BaEv7k89pW82NQAq3GL5M9yvxJ82JCxx0ndSiS696i4M0q/cXqVrcrZ1id7yn2 hHNqpNGqEWjVhguYb9cmcc71AGd+ -----END CERTIFICATE----- subject=/C=IL/ST=HaDarom/L=Eilat/O=StartCom Ltd. (Start Commercial Limited)/OU=StartCom Extended Validation/CN=www.startssl.com/emailAddress=webmaster@startssl.com/serialNumber=513747303/2.5.4.15=V1.0, Clause 5.(b)/1.3.6.1.4.1.311.60.2.1.3=IL issuer=/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Extended Validation Server CA --- No client certificate CA names sent --- SSL handshake has read 4650 bytes and written 334 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: E4B461C13F254C609BD5962159A1E427FE7242DEA310BCBCB1576F07F27DFBF3 Session-ID-ctx: Master-Key: 72F980334BC9403772D855382A9A16200AA86EFD16F79DDAC16F1E44A904D60F1B58BEFEADB11B5EAF16E70A6F3F6E6B Key-Arg : None Krb5 Principal: None Start Time: 1264858060 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- closed Firefox has built in: StartCom Certification Authority: issued on 9/17/2006, exp: 2036 StartCom Extended Validation Server CA: issued on 1/1/2009, exp: 2019 StartCom Class 2 Primary Intermediate Server CA: issued on 10/24/2007, exp: 2012 Free SSL Certification Authority: issued on 3/17/2005, exp: 2035
Try this: wget http://www.startssl.com/certs/ca.pem openssl s_client -CAfile ca.pem -connect www.startssl.com:443 Regarding your failure to validate the CA root in the browser, I'm not sure which versions and systems you were using, but Firefox has the new root since 2007. Regarding the client certificate, make sure that it's valid. If it expired it obviously won't work either.
Yep, that works with openssl. Already been there :) The problem is that Firefox has it "already installed" in the built-in objects, but it apparently has a difference between what Firefox visualizes and what is actually in ca.pem. This is why Firefox users can't use it.
I'm not sure what you mean with "Firefox users can't use it". OpenSSL doesn't use the built-in CA certificates of the NSS DB. NSS has however the exactly same CA certificate you just downloaded.
What I meant is, the built in object (StartCom CA) looks like your ca.pem; on disk the files are identical. In practice, Firefox has some munged idea about it. part a) i opened this bug from the "verifies but can't verify" remark; when you try to load your page, Firefox can't verify your cert. However if you view the details, or try to manually override it, Firefox states that the cert is valid and won't let you add an exception. part b) in the past we could load your ca.pem because you weren't in the root and we could then recognize websites with startssl certificates. we can't load it now because Firefox already has it, and has a split brain notion about whether or not it can use it for verifying certs Mind you, I can visit other https pages on startssl.com just fine. It's something with the cert negotiation for the login/auth page. Something in -that- negotiation only is failing, and the only feedback we have (on all browsers) is that we can't validate the certificate. If your certificate was really invalid, we should get that warning/error for every https page, no? What makes the logon.ssl URI different?
OK, there is a misunderstanding. The error code for the authentication is ssl_error_handshake_failure_alert, it's not sec_error_unknown_issuer. It has nothing to do with the CA root. Hence your efforts to override anything were fruitless (and might have made things even worse). This location requires a client certificate, see comment 3. The required client certificate is provided to our subscribers during registration and without it you can't authenticate. Unfortunately the error message in the browsers aren't very helpful, including that of Firefox :-) I suggest that we close this bug as invalid or worksforme. Johnathan can think about a better way to support client certificate authentication in the UI if he wants.
I have a client certificate, it's valid, I got it three weeks ago. It is installed in both Firefox and Opera. I've mentioned that in comment 1 and comment 4. :) I can log in using it in Opera but your javascript and Opera do not get along very well. Some things just won't work and other things work improperly.
On which OS is that? Is this vanilla Firefox as downloaded from the Mozilla download site? I suspect it's not. Continuing with my assumptions, try to set "export NSS_SSL_ENABLE_RENEGOTIATION=1" before starting Firefox.
That worked perfectly, UI to allow presentation of my certificate and the page then immediately loaded.
Icewisel is not a product of Mozilla.
Iceweasel is the rebranding applied to distribution built Firefox code due to licensing issues.
Debian modifies the sources amongst other things. That's why they can't brand it as Firefox. Please download a real Firefox from Mozilla and you'll see, that the from you reported issue, doesn't apply.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
I forgot to mention that you obviously can, and perhaps should file a bug report with Debian. The bug report you mentioned above remained unfixed to my understanding.
I know why it gets rebranded. I don't use Debian, I use Gentoo. Mozilla doesn't make an x86_64 build. I'll open a bug with Gentoo and see what comes of that. The Gentoo patches list for Firefox is three entirely unrelated and short files. Why is negotiation required? At the moment, nearly all software packages have disabled renegotiation due to the SSL TLS protocol vulnerability.
I assume it's a necessity for the client certificate authentication?
(In reply to comment #20) > I assume it's a necessity for the client certificate authentication? Yes - the only reason when this should really happen (at the moment). Gentoo is similar affected like Debian. They are the only two Linux distributions which have that problem right now and to all of my knowledge.
Marking reopened. This UI bug needs to be fixed. The UI is incorrectly reporting certificate validation fails while what is actually is a failure to renegotiate. Failure to renegotiate is caused by an update to libnss intentionally disabling renegotiation, or a protocol disagreement. This is not a Linux distribution fault. Debian (and Gentoo, both arch and ~arch) are early adopters of the updated libnss software package. The UI should indicate the correct reason for failure (and indicate if renegotiation is intentionally disabled with instructions to enable it, including applicable warnings). The 3.12.5 release of libnss by Mozilla (NSS) disables renegotiation of SSL connections by default. This is intentional until the IETF working group finalizes the TLS changes to the SSL protocol.[1] The IETF approved the working group protocol update in early January. Until this is formally adopted in the specs, and subsequently adopted in software packages, expect to require this workaround. This TLS bug is primarily a server problem but it is easier to avoid en-mass by disabling renegotiation in the browser. To re-enable renegotiation in your browser, export NSS_SSL_ENABLE_RENEGOTIATION=1 in your environment before starting Firefox (or rebranded packages). Within an application, SSL_ENABLE_RENEGOTIATION can be set to SSL_RENEGOTIATE_NEVER or SSL_RENEGOTIATE_UNRESTRICTED. 1. https://developer.mozilla.org/NSS_3.12.5_release_notes
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This is handled at different bugs and current Firefox releases are not affected. See for example bug 540304, bug 535649 and bug 537356.
Current binary release of Firefox 3.6, fresh blank profile, with no certificate installed still shows a handshake failure saying it can't verify. Bug 540304 is reopened, the other bugs are still marked new and I don't see the patches applied to the source.
blu3: i don't care. resolving invalid. do not reopen. using minefield, i get: Secure Connection Failed An error occurred during a connection to startssl.com. Renegotiation is not allowed on this SSL socket. (Error code: ssl_error_renegotiation_not_allowed) This was from bug 540332 (fixed on trunk). According to that bug, bug 545755 would be the equivalent for branches. Your bug is wasting space and confusing people.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → INVALID
the original error message was entirely different. my suggestion was to indicate the correct reason why the connection failed. see comment #22. it's been fixed in exactly this manner. it doesn't need reopened. your sarcasm and directive isn't applicable to this bug. the further information to get firefox working with some websites was added for those people who encounter this (bug|feature).
You need to log in before you can comment on or make changes to this bug.