Build: 2001072408, Mac OS 9.1 To reproduce: * Go to a page for which the security certificate has expired. What you see: +-----------------------------------------------------+ |::: Security Error: Security Certificate Expired ::::| +-----------------------------------------------------+ | "*.Fortify.net" is a site that uses a security | | certificate to encrypt data during transmission, | | but its certificate expired on 2001-03-07 10:31 PM. | | | | You should check to make sure that your computer's | | time (currently set to Thursday July 26 23:32:19 | | 2001) is correct. | | | | Would you like to continue anyway? | | | | ( View Certificate ) | | | | ( OK ) ( Cancel ) ( Help ) | | | | | | | | | | | +-----------------------------------------------------+ What you should see: +-----------------------------------------------------+ |:::::::::::::::::::::::::::::::::::::::::::::::::::::| +-----------------------------------------------------+ | . There is a problem with the security | | /!\ certificate for "*.fortify.net". | [cropped, w. line break] | """ Are you sure you want to continue? | | | | The certificate expired on 2001-03-07 10:31 | | PM. (The time on your computer is 2001-07-26 | | 11:32 PM.) | | | | ( View _Certificate ) | | | | [ ] _Accept this certificate permanently | | | | [?] ( Cancel ) (( Continue )) | +-----------------------------------------------------+ The fix for this bug should share a lot of code with the fix for bug 91466 -- the introduction and checkbox strings used here are clarified versions of the ones used for that alert, and should be used for both alerts. The tricky bit in this bug will be fixing the date formats. Ideally, the format for neither the expiration date nor the current date should be hard-coded, but should use the relevant system settings for short dates; if that can't be fixed easily, a separate bug should be filed for it. A separate bug should also be filed for `Accept this certificate permanently', if that is not currently possible for expired certificates (so you can wander around ghost HTTPS sites as easily as you can wander around ghost HTTP sites).

Is there a tracking bug for these "* is horked" bugs?

As for sharing XUL code, I know it is possible but I don't consider that high priority at the moment. First step is to un-hork the dialogs, then optimize and polish them.

p3 t->2.1

Mass assigning QA to ckritzer.

Changing component to browser-general so I can change the milestone; 2.1 doesn't mean much to me. I want a 0.9.x milestone...

Explanation for the opposite case: | | | The certificate will not be valid until | | 2001-10-01 12:00 AM. (The time on your | | computer is 2001-08-13 02:03 AM.) | | | | ( View _Certificate ) | Håkan tells me that this might require some fixes to the C++ back end, so it may have to go in a separate bug.

I can't fix this until someone on the Security/PSM team does me a favor and fixes bug 94972.

Changing back to PSM. The 2.1 PSM target is equivalent to 0.9.4. As module owners we need to be able to manage our bug according to criteria we set. Thanks.

The owner of this bug is not a Netscape employee. Please don't change it out from underneath the owner.

Stephane Saux, this is not your bug. Pleas do not change fields of bugs which belong to other developers. Doing so is rude and inappropriate. If you would like to make changes to someon else's bug please ask them first. --Asa

Could you change my bugs back, please?

Ok, I should have explained first. My apologies. PSM has its own policy for numbering their product. This bug used to be PSM and the module owners were not consulted when the fields where changed. If the only reason why the product and component were changed is that the 2.1 means nothing to Hakan, the answer to that is that the release that goes with 0.9.4 is 2.1. From Hakan's perspective, having the bug numbered 2.1 should thus be equivalent, and having the bug properly belong to PSM allows us to have a good understanding of what is changing in our module. Comments?

Move to future. Won't have time to fix these for 2.1

Stephane, please DO NOT change the Target Milestone on bugs that are not assigned to you. _You_ may not have time to fix this for 2.1 bug Haakan has indicated that he does. It is impolite and against Bugzilla good practices to change the TM of other people's bugs. This is the second time you've made such a change to some one else's bug and this is final request/warning that you stop doing this.

Reassign.

Preferably we should skip this middle step which still leaves our SSL cert UI sucking, and go ahead with the full blown fix in bug 99411. Want to take a stab at a dialog there, mpt?

The design for bug 99411 is fairly obvious, and I think very little of the code for this bug would end up being thrown away when that bug is fixed.

Another note - I've got a site which just updated it's certificate because the old one had expired, but there seems to be no mechanism to tell mozilla to get (and use) the new one. If I could delete the old, expired one all would be well (but this is broken due to things like bug 165650). Neither the current expired dialog nor the "accept this forever" dialog above offers an option to look for a new cert. Am I missing something? Perhaps there is something wrong with how the cert was constructed?

Michael... Mozilla does not remember sites' certificate... it always uses the one the server sends.

Would be nice to resolve this (to be able to "Accept this certificate permanently"), cause too many sites use expired certificates :((, and users always should click that Ok button.

Since the main point of certificate expiration dates is to earn Verisign more money, I think we should not pop up an alert at all for this condition. Maybe a slightly different 'lock' icon in the corner, and certainly a note inside the security part of page info, but a modal dialog warning scaring the user and forcing the site to chuck more money over to Verisign?

On https://lists.xcf.berkeley.edu/lists/advanced-java/1998-November/014068.html this pop-up comes up. And when clicking ok, it comes up again, and again and again and again and again and... well you get it. Is this related or is it a seperate bug.

Mr. Houwing, that's a new bug so I filed bug 175824.

Mass reassign ssaux bugs to nobody

Mass change "Future" target milestone to "--" on bugs that now are assigned to nobody. Those targets reflected the prioritization of past PSM management. Many of these should be marked invalid or wontfix, I think.

First stab at a test patch for this bug. Kaie: I want to take a stab at remaking all these dialogs and make them more consistent. Do you want me to attach a patch for an overall makeover, or do them one by one? Also, obviously, since the nsIBadCertListener interface is FROZEN, we have to make a nsIBadCertListener2 interface or something to support the checkbox in all the cert dialogs (which should eventually only be 1 dialog, if I do this like I intend) - as you can see I modified nsIBadCertListener here and didn't even change the IID, since this is just a patch to get the discussion going. How would a new superinterface be handled? Is it possible for consumers to say "I support this interface.", so that if they don't we fall back to not showing the checkbox? Also need to remove the unnused strings from the language files. Screenshot coming.

mpt: What do you think? In your initial proposal, you had an extra button called "View Certificate", but I'm not sure if the concept of a "disclosure button" existed then? Every dialog has the ability to have a "disclosure button" now, that is supposed to be used for things like this. I guess it was added so that there was a common way of exposing "give me more info" to the user.

dveditz: I have no idea if Kaie still does reviews .. Since you're the owner of the Security component, I thought you might know something. If not, who should I request review from (we're talking about UI changes)?

I will review it later today.

Comment on attachment 198576 [details] [diff] [review] test patch >Index: pki/src/nsNSSDialogs.cpp > nsCOMPtr<nsIX509CertValidity> validity; Actually, we could just pass this through with the nsIPKIParamBlock and do all the time magic in JS, or, since we have the cert there already, just cert->GetValidity in JS? >+ nsXPIDLString commonName; > rv = cert->GetCommonName(commonName); >+ nsCOMPtr<nsIDialogParamBlock> dialogBlock = do_QueryInterface(block); >+ rv = dialogBlock->SetString(1,commonName); We already have the cert in our nsIPKIParamBlock, so we can also just get this name in JS - no need to send an extra string. Anyway, what I'd like to do is create a dialog that shows all the errors in a certificate, so that we get out of this show-4-dialogs-in-a-row mess for the worst certificates. I was thinking along the lines of a new IDL (nsIBadCertListener2 or something): boolean confirmBadCertificate(in nsIInterfaceRequestor socketInfo, in nsIX509Cert cert, in AUTF8String targetURL, [array, size_is(messagesLen)] in short messages, in unsigned long messagesLen, out short certAddType); that also defines the 4 error message types we can show: const short MESSAGE_UNKNOWN_ISSUER = 1; const short MESSAGE_DOMAIN_MISMATCH = 2; const short MESSAGE_EXPIRED = 3; const short MESSAGE_CRL_EXPIRED = 4; and then nsNSSIOLayer would "convert" the SEC_ERROR's to MESSAGE's and request one dialog instead of one per message. Maybe you'll just want to send in the SEC_ERROR's instead? Or maybe you want the MESSAGE's to be bit flags? Or maybe you have a whole different method signature in mind? :-) Maybe we should move this discussion to a more suitable bug, if there is one.

Vidar, thanks for your willingness to work on this topic. However, before I review your patch, I have a couple of thoughts. Well, I have tried your patch. In my opinion, it does not do what the UI appears to do. I clicked the checkbox, but on restarting the program, I was again warned that the certificate has expired. So I'm not sure what the intention of your patch is. Anyway, I would like to propose that you split your work into two completely separate steps. Doing Mozilla UI changes is often difficult to get approved. There are many people who have thoughts and you will hear a lot of different opinions. Because of that, I propose you begin by working out the complete set of all UI changes you want to do. If you do coding, just do the XUL work. Only so you can attach screenshots. As a first step, try to convince people that your new UI is better than the existing one. And describe what should happen when you use the UI. For example, when I read this bug, it was really not clear to me, what the checkbox should do, and it actually didn't do what I expected. I think it does not make sense to review a patch, as long as it does not work, and the UI proposal is not yet accepted. Please feel free to explain more, if you have the feeling that I misunderstood.

Comment on attachment 198576 [details] [diff] [review] test patch (In reply to comment #31) > Well, I have tried your patch. > In my opinion, it does not do what the UI appears to do. I clicked the checkbox, > but on restarting the program, I was again warned that the certificate has > expired. So I'm not sure what the intention of your patch is. That's strange. It uses the exact same code for storing the certificate as the ConfirmUnknownIssuer dialog. I'll look into that later, then. > Doing Mozilla UI changes is often difficult to get approved. There are many > people who have thoughts and you will hear a lot of different opinions. Because > of that, I propose you begin by working out the complete set of all UI changes > you want to do. If you do coding, just do the XUL work. Only so you can attach > screenshots. Yes, that's true. I'll try to produce some more screenshots.

See bug 99411 for prototype.

Please correct me if I'm wrong. This bug asks for the possibility to remember expired certificates permanently. The bug subject should say that (instead of saying it's broken). If my understanding is correct, I'd like to change this bug to "enhancement".

In any case, as it is now, I think this bug should get fixed by an implementation of the prototype in bug 99411?

*** Bug 307977 has been marked as a duplicate of this bug. ***

*** Bug 321185 has been marked as a duplicate of this bug. ***

Hi, can somebody tell me now to change the status of this bug to "Major"? This bug is effectively preventing me from using the application (version 1.5.0.12).

I have done a bit more digging, and found that the suggested solution to this problem (see link below), worked for me, and I can at least us it now. https://bugzilla.mozilla.org/show_bug.cgi?id=221552#c20

Kai - is this fixed (on trunk) as a result of bug 387480?

If this bug is about web pages only, then this bug is fixed. If this bug is supposed to complain about SSL connections to mail servers, too, then this won't be completely fixed until we add support for arbitrary ports in 387480 (which I hope to do soon).

Ahh, my mistake I think. I was referring to TB...I think I've had a similar problem in both.