1002453 - StartSSL certificate has weird name le-8bbf0da1-ccce-44d9-.......

Status: UNCONFIRMED

(Core :: Security: PSM, defect, P3)

Description

[RINNTECH]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 (Beta/Release)
Build ID: 20140318183706

Steps to reproduce:

I have a class 1 certificate from StartSSL. I want to login to https://auth.startssl.com/ .

The certificate has following subject:
E=...,CN=...,OID.2.5.4.13=5N8....


Actual results:

In the dropdown-menu, the certificate has a weird UUID-name "le-8bbf0da1-ccce-44d9-....... [serialnumber]" instead of the CN.


Expected results:

Instead of that UUID, the output should be "[CN] [serialnumber]"

Comment 1

[RINNTECH]

Note: I tested it with Firefox 31 Nightly using mozilla::pkix

Comment 2

[u279076]

Matt, could you see if you're able to reproduce this?

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

The URL above does not connect due to an internal SSL error.

The steps in this bug seem incomplete. To investigate, we need to know what URL to use, what UI you're looking at, and what builds you've tested. We'd like to know if this has ever worked, and if so, which versions of Firefox work and which ones fail. It also helps to try in another browser to see if there's any difference.

In short, this bug needs more info to be actionable. Please provide that information and we'll be happy to look at it.

Comment 4

[u279076]

Thanks Matt.

RINNTECH, please follow-up in this bug with the information Matt needs as soon as possible.

Comment 5

[RINNTECH]

Hello,

this URL does work, but it does only work if you have a (free) certificate from StartSSL. That is no internal SSL error. You simply don't have a valid certificate to enter the login area.

I can always reproduce this issue and I have attached a screenshot. It never worked. It also happens on SeaMonkey. In Internet Explorer it works perfectly and is userfriendly. Not as in Firefox. See additional screenshot.

Here is the link to StartSSL where a certificate can be registered and where the login URL appears: https://www.startssl.com/?app=11&action=true .

I have many certificates from StartSSL and when I login I need to select which certificate I want to use to authentificate myself. It is very user-unfriendly since Firefox shows every certificate in the dropdown-box as cryptical name. Internet Explorer shows a nice dialog with the "CN" and validity range, so I can choose the correct certificate.

Comment 6

[RINNTECH]

Attachment: startssl-firefox.png

Client-Certificate dialog shows cryptical names for StartSSL certificates instead of printing the CN.

Comment 7

[RINNTECH]

Attachment: startssl-ie.png

Internet Explorer does it correct and shows a nice dialog with CN, CA and validity range.

Comment 8

[RINNTECH]

Here is an example of a StartSSL certificate where Firefox/Seamonkey does not show the CN in the dropdown box: https://www.viathinksoft.de/cdr/viathinksoft.de/info/31998ab376f5fbf398790258fa39ac14024ce548/

Comment 9

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to RINNTECH from comment #5)

> Here is the link to StartSSL where a certificate can be registered and where
> the login URL appears: https://www.startssl.com/?app=11&action=true .

If I need to access that URL or https://auth.startssl.com to reproduce this bug, I cannot. No browser I tried - IE, Chrome, Safari or Firefox - can access that page due to a problem negotiating an SSL handshake. This may be due to not having the correct certificate(s) installed, but how do I obtain that?

I downloaded the cert linked in comment 8, tried to add that manually as well via the Certificate Manager before going to the site, but still same problem - site cannot connect, same error. 

I would like you to provide a numbered set of steps to reproduce this bug. Please assume that this is a new browser profile, without any custom certs or preferences. Also, if there is more than one place in the UI where this odd string shows up, that would be good for us to know as well.

I want to understand what is happening here, but I will need your help. Thank you.

Comment 10

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Matt - I had to sign up for a (free) email certificate from StartSSL for auth.startssl.com to work (although for a while I think it was broken for everyone - it seems to work now).

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: mwobensmith_cert_dialog.png

Thanks David. The site seems to be up now. 

I was able to register and receive my free cert. I installed it, and got the dialog to display. For me, the CN shows up correctly ( see attachment ) so I don't know what the difference between our certificates might be.

Comment 12

[RINNTECH]

Attachment: both certs.png

Hello Matt,

I have interesting news. Yesterday I have requested a new certificate from StartSSL and for this certificate it works.

Here is a comparison of my certificates:

Old certificate 2013: https://www.viathinksoft.de/cdr/rinntech.com/daniel.marschall/cdb8f20d27b0f1bf7cb61f20b1042e493cbfa4fe/ (does not work)

New certificate 2014: https://www.viathinksoft.de/cdr/rinntech.com/daniel.marschall/42646e3406bde2e9ca12f209f52ce35dfeb1d098/ (does work)

Looking at the text output, they seem to be nearly no difference. The subject DN has the same set of attributes, the CA is the same, as well as other stuff (CRL references etc.). The only notable difference seems to be the RSA public key length.

The old certificate which DID NOT work used 4096 bits.

The new certificate which DOES work uses only 2048 bits.

So, I assume, as soon as the RSA key is too big (4096 is not THAT big, Firefox should support that!), the certificate will be displayed as UUID instead of the user-friendly format "<Subject CNs>'s <CA CN> certificate [<Serial>]" .

Since this behavior happens in the old implementation as well as in the new mozilla::pkix implementation, it could be an expected behavior (theory), to avoid that too large certificates will delay the certificate-listing process. So if the certificate is probably too long, it will just be shown as GUID. If this theory is true, you should increase the limit (e.g. to 16384 bits) or remove it completely. Today's computers are so fast, that a 4096 bit key is no reason to fear that it might delay a listing process. Also, most users will only have 1 or 2 certificates installed in their private storage, so even if the parsing needs 100 milliseconds, you should be still fast.

Comment 13

[Matt Wobensmith [:mwobensmith][:matt:]]

Thanks for the research! That's a good question. Would the RSA key length affect how we display the CN in our UI? Is this expected behavior? Is there an upper limit to what we'd support?

David, any ideas?

Comment 14

[Kaspar]

Most likely the same issue as reported in bug 450559.

See also https://groups.google.com/d/msg/mozilla.dev.tech.crypto/dBQr2ioUIdE/VbaeJ48-SBQJ

Comment 15

[RINNTECH]

Attachment: IE-friendly-names.png

I haven't thought about this. I just tested both certificates in Internet Explorer and found out that the 2013 certificate does not have a friendly name, while the 2014 certificate has the friendly name as seen in Firefox.

I created the certificate last year with Internet Explorer. which didn't set a friendly name. Therefore the PKCS#12 file did not contain any. This year I created the certificate with SeaMonkey which added the friendly name, and then I ported the certificate via PKCS#12 to Firefox, which is showing the friendly name.

Solution: Please, instead of showing a GUID which nobody understands, show a user-friendly string if the certificate does not have any user-friendly name. There seems to be already code which creates such a user-friendly name ("<SubjectCN>'s <CA CN> ID") in the certificate enrolment process.

Comment 16

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Right, this isn't related to key size. We can certainly improve the UX here.