Closed Bug 315044 Opened 19 years ago Closed 15 years ago

Unable to always accept some certificates (e.g. with unverified issuers) in Camino

Categories

(Camino Graveyard :: Security, defect)

Product:
Camino Graveyard
Component:
Security
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jbrsh, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 There are some secure websites that I frequently visit that use a certificate. Camino presents the details of the certificate with a message telling me "Unable to verify the identity of "(website)" as a trusted site. The cerficate if valid until February next year. I'd rather not disclose the address, I can provide it for the developers if they need it for testing. The problem comes when I try to click "Always Accept". The dialog closes then re-opens with the same message. It will continue doing this indefinitely. The only workaround is to click "Stop" or "Accept One Time Only". These both work as expected. Since I don't know much about certificates, I can't tell whether the problem lies with the site or with Camino. I don't have this problem with Firefox though. Reproducible: Always
*** Bug 315050 has been marked as a duplicate of this bug. ***
*** Bug 315047 has been marked as a duplicate of this bug. ***
*** Bug 315045 has been marked as a duplicate of this bug. ***
Oops, sorry, don't know what happened there. I seem to have somehow filed the bug three times without knowing it. My apologies.
I wonder if I have the "Always Accept" and "Accept one time only" buttons reversed...
Assignee: dveditz → sfraser_bugs
URL: https://ub-bib3.ub.uni-greifswald.de/...
Status: UNCONFIRMED → NEW
Ever confirmed: true
I was able to reproduce this once or twice, but most of the time it works fine. I checked our return values in the code, and we're doing the right thing. Reporter: does it happen every time you visit the site (if you delete the accepted cert in between, and quit and relaunch)?
I can't uncheck the "Trust this certificate for: Identifying web sites (for SSL)" box after I've checked it, either, and checking it makes that particular dialog start showing up for me after it hadn't been.
Er, nevermind, I guess; now it's not sticking at all.
I thought I'd already posted this comment but bugzilla is either refusing to submit them or I end up with 4 identical bugs like before. The forums are playing up too- telling me PHP failed but submitting my post anyway. I'll try again: Simon- yes it was happening each time I visited the site even if I quitted and re-launched. But deleting the certificate fixed the problem. I went back to the site and clicked Accept Always after deleting the certificate and it stuck this time. I'm thinking that the first time I encountered the certificate I must have selected Accept One Time Only since that is the default option. That's why it asked me each time I went to the site. But for some reason I couldn't click Accept Always after that until I deleted the certificate so I guess it's still a bug.
Actually I'm beginning to think maybe it was just some sort of corruption in the certificate. I deleted it again and clicked Accept One Time Only. I then re-launched and it asked me to accept again as expected so I clicked Always Accept and it worked fine, hasn't asked me to verify it since then. I did notice that originally the certificate was stored under "Authorities" in the certificates window when I was having the problems. When I deleted it and accepted it again, it now stores it in the "Web Sites" subset. I'm not sure if this is significant at all. Will let you know if the problem re-surfaces.
(In reply to comment #7) > I can't uncheck the "Trust this certificate for: Identifying web sites (for > SSL)" box after I've checked it Yeah, we don't save trust changes for unverified certs (e.g. unknown issuer). Firefox has a different UI that shows in this case, and we need some more UI too.
Hi Simon, It's been a year since anybody commented on this bug, but I have a few observations to add. In my case, I need to add a new root CA and have Camino trust it. In 1.0.3 I can check the appropriate boxes and Camino will save the settings. In other words, all is well. However, using the latest nightly builds Camino will not save those boxes as checked. It continues to say that the root CA is not valid for unknown reasons. What's worse, I can take another valid root CA and uncheck one of its trust settings, but then I will not be able to trust it again. My workaround is to reinstall 1.0.3 and set my trust settings as I need them to be set, then go back to the alpha. It seems that this problem is related to the original bug report, but if it is not I'd be happy to file a separate one. Hope it helps, Adam
Adam, my gut feeling is that yours is a different bug, since it works in 1.0.x and not in 1.1.x, but we can see what smfr says. Can you check a hunch for me, though: download a build from http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/latest-1.0-M1.8.0/ and see if your "1.0.3 work-around" still works with that build (it's what will become Camino 1.0.4, and it includes changes to security subsystems that prior to a few weeks ago had only landed on the 1.8 branch and trunk, not 1.8.0 branch (1.0.x)....
Hi Smokey, The version you pointed me to is still able to "re-trust" my new root CA. I noticed that the error messages for invalid certs are also more descriptive in the 1.0.x series, i.e. I get "Not trusted" when I uncheck the boxes in 1.0.x, and some other certs say "Expired", but in 1.1.x every invalid cert only says "Unable to verify". Don't know if it's helpful...
Hi, Just thought I'd confirm that this inability to trust root CAs is still present in today's nightly beta. Regards, Adam
I'd like to move discussion on trusting root CAs (comment 12 et seq.) to bug 383988 instead, and keep this bug focused on the inability to trust unverified certificates, because of both comment 11 and because comment 12 seems to imply a regression subsequent to 1.0.x.
Summary: Unable to always accept some certificates in Camino → Unable to always accept some certificates (e.g. with unverified issuers) in Camino
I had something between a hunch and a wild guess today, so I whipped up this build which includes some stuff we heretofore were not including: http://www.ardisson.org/smokey/moz/Camino-Branch-20071128-CertifTest.dmg (this is roughly today's Camino 1.6a1pre build with my changes) Ben, Adam, can you guys check and see if this build fixes this bug (unable to accept certifs with unverified issuers) for you?
Hi Smokey, I tried the build in your link and the latest nightly -- both seem to work fine w.r.t. to this bug. I have no difficulties clicking "Accept Always" when the site cert "cannot be verified for unknown reasons. Regards, Adam
What's the status of this bug (unable to "always accept" certs with unverified issuers) with the new UI in Camino 2.0a1pre builds? Does the new exceptions model (which replaced this UI) allow these certs to work as expected now? Note: if you're not regularly using the 2.0a1pre builds <http://caminobrowser.org/download/releases/nightly/>, you should only test them using Troubleshoot Camino <http://pimpmycamino.com/parts/troubleshoot-camino>, since there are irreversible profile changes that make profiles used by 2.0a1pre unusable with Camino 1.6.x.
Assignee: sfraser_bugs → nobody
Actually, sort-of answering my own question, the URL smfr added to the URL field seems to work fine on there, since I used it in testing bug 398417.
Believe it or not, at some point in time this fixed itself on the MOZILLA_1_8_BRANCH; I just tested 1.6.10 (with https://www.cacert.org/, since the URL in the URL field is gone now). Incidentally, this is the same thing Adam said in comment 19 back in April 2008, and somehow I missed that entirely :P
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.