Firefox crashes when accepting new certificate permanently on taschenonkel.de https://bugzilla.mozilla.org/show_bug.cgi?id=298906 has a hotfix for this issue. Reproducible: Always Steps to Reproduce: 0) Load https://taschenorakel.de/ 1) In the cert dialogue, choose "Accept this certificate permanantly" and click OK 2) Crash!
I can replicate with your site alone unless you can come up with another site that causes such an issue nothing I can do but sit here and believe it is a web site issue not browser. I am gonna close bug report as NEEDINFO before I can go any further if you disagree you can reopen and address your concerns.
A segmentation fault *NEVER* is a web-site issue. You really should try to integrate the patch from upstream, before someone with "leet haxor skills" discovers those bug reports and constructs an exploit for this problem.
No crash here... but it seems the server doesn't want my business (connection times out). That said... I recently upgraded the security certificate on two servers I run (using self-signed certificates) and had no issues. https://stuartl.longlandclan.hopto.org/blog/ <-- That's my blog accessible via https. I just had the cert dialogue appear when visiting that site (as I've never tried accessing my blog via https before), and so far, no crash. So it's not Firefox having difficulty with self-signed certificates per-se. (And until tashenorakel.de wakes up and answers my TCP SYN, I won't know otherwise). Given that it's apparently "FIXED" upstream, perhaps you'd like to consider trying a newer version of Firefox and see if this is indeed the case? Thanks.
This bug cannot be triggered by taschenorakel.de anymore, because I've replaced the certificate in the meantime. To trigger it your web-server has to supply a certificate containg an excessive long CN record (> 250 chars?). Had such a CN because the limitations of TLS to handle virtual hosts (CN=taschenorakel.de|www.taschenorakel.de|mail.taschenorakel.de|.... - you get the picture). AFAIR installing the fixed version lib libnss fixed the problem for me, but I am not sure. Too long ago that I reported this security problem. If you care you should create such a certificate on you own and check back.
Ahh okay... so the issue is more of the length of the Common Name (CN) field. This is a useful clue, as it suggests a boundary checking or buffer overflow issue -- which has some particularly nasty implications if you think about it. This is something I will look into. To be honest, I didn't know you could list multiple common-names, except using wildcard syntax (you'll notice my blog uses a CN of *.longlandclan.hopto.org). But now that I know it's possible, I'll look into this further. What can I say, you learn something new every day. :-D
Resolving as upstream via anarchy.