From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 271F01384C3 for ; Sat, 5 Sep 2015 13:07:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A34109585F; Sat, 5 Sep 2015 13:06:35 +0000 (UTC) Received: from acheron.yagibdah.de (acheron.yagibdah.de [185.55.75.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3D9BC9580C for ; Sat, 5 Sep 2015 13:06:33 +0000 (UTC) Received: from br-dmz-ip.yagibdah.de ([192.168.1.1] helo=heimdali.yagibdah.de) by acheron.yagibdah.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.85) (envelope-from ) id 1ZYDAu-0004SW-3T for gentoo-user@lists.gentoo.org; Sat, 05 Sep 2015 15:06:32 +0200 Received: from lee by heimdali.yagibdah.de with local (Exim 4.84) (envelope-from ) id 1ZYDAu-0005qd-1F for gentoo-user@lists.gentoo.org; Sat, 05 Sep 2015 15:06:32 +0200 From: lee To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] broken seamonkey :( In-Reply-To: (Fernando Rodriguez's message of "Fri, 4 Sep 2015 21:08:47 -0400") Date: Sat, 05 Sep 2015 15:06:27 +0200 Organization: my virtual residence Message-ID: <87613pkobw.fsf@heimdali.yagibdah.de> References: <87oahjmg8s.fsf@heimdali.yagibdah.de> <87k2s5lra5.fsf@heimdali.yagibdah.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Mail-Followup-To: gentoo-user@lists.gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 3f93b15d-ffee-4776-828a-5239c0689b56 X-Archives-Hash: 18bca864f53e8e642c6aa6c4c4500f41 Fernando Rodriguez writes: > On Saturday, September 05, 2015 1:05:06 AM lee wrote: >> In this case, I happen to have full physical access to the server and >> thus to the certificate stored on it. This is not the case for, let's >> say, an employee checking his work-email from home whom I might give the >> login-data on the phone and instruct to add an exception when the dialog >> to do so pops up when they are trying to connect. > > As a workaround you can create your own CA cert. I tested with a windows = self- > signed cert (I guess the correct term is self-issued) and the openssl com= mand=20 > will show two certs. The second is the CA. > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica= te-authority/ They're saying: "Whatever you see in the address field in your browser when you go to your device must be what you put under common name, even if it=E2=80=99s an= IP address. [...] If it doesn=E2=80=99t match, even a properly signed certif= icate will not validate correctly and you=E2=80=99ll get the =E2=80=9Ccannot veri= fy authenticity=E2=80=9D error." What's the solution for a server which can be reached by different fqdns and IPs? What if the fqdns and IPs it can be reached by change over the lifetime of the certificates? How do I deploy some sort of central infrastructure all clients on the LAN and anywhere on the world will automatically use to do the simple thing of adding an exception (or whatever is required for that) so that seamonkey and relatives can be used to access email? That's letting aside that it's ridiculous to deploy such an infrastructure when the same thing could be achieved by the user clicking a button once to add an exception, as it used to be. Seriously? The result is currently a version freeze; the alternative is using unencrypted connections. After some time, the version freeze cannot be kept up. Since there are no alternative MUAs, we can only go back to unencrypted connections when that happens. And that's something I don't even want to do on the LAN. Well, I've made a bug report about this: https://bugzilla.mozilla.org/show_= bug.cgi?id=3D1202128 --=20 Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.