1226203 - SSL connection hangs indefinitely when CN of the certificate contains only a simple hostname without domain

Status: RESOLVED DUPLICATE of bug 1056341

(Core :: Security, defect)

Description

[Claudiu N. CISMARU]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 2015103000

Steps to reproduce:

Point Firefox to a SSL site which has a CN with only the hostname without domain (for instance, CN contains only "site1")

The platform is Linux.


Actual results:

The tab remain in "Connecting...". High CPU is observed.


Expected results:

The website to open eventually with a Untrusted connection page.

Comment 1

[Claudiu N. CISMARU]

If you need more information, please ask.

Comment 2

[Claudiu N. CISMARU]

Want to mention, also, that the certificate is self signed.

Comment 3

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

Please attach the certificate that is failing. Incidentally, are there many certificates with the same subject distinguished name in your certificate database?

Comment 4

[Claudiu N. CISMARU]

David,

You have a good point in here.

I'm working with new installed devices in the labs. These devices uses the same certificate DN at install time. So, yes, the database contains many certificates with the same DN, which I trusted on the browser.

Comment 5

[Claudiu N. CISMARU]

Attachment: A sample of certificate, as requested.

Comment 6

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

Thanks for the certificate. Based on comment 4, this is the same as bug 1056341. See in particular b 1056341 c 16 and b 1056341 c 24. Basically, based on the certificate verification architecture, this is a pessimal case. You should be able to make the symptoms less painful by periodically clearing the certificates in your database or using a new profile.

Comment 7

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

(In reply to David Keeler [:keeler] (use needinfo?) from comment #6)
> Thanks for the certificate. Based on comment 4, this is the same as bug
> 1056341. See in particular b 1056341 c 16 and b 1056341 c 24.

Hmmm. That syntax doesn't appear to work. That should be bug 1056341 comment 16 and bug 1056341 comment 24.