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 BCB921384C3 for ; Sat, 5 Sep 2015 22:25:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D62C142F6; Sat, 5 Sep 2015 22:24:53 +0000 (UTC) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 E19F414294 for ; Sat, 5 Sep 2015 22:24:51 +0000 (UTC) Received: by wicge5 with SMTP id ge5so48260722wic.0 for ; Sat, 05 Sep 2015 15:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=8oFGCdSLrWjfLAgrKheE8DWyZ4Xuy5QG98lJVjP4Das=; b=TdWsyg6sIfTxXLb1Yt7NrEann/odV63MkmDWaMh5TEb9uKARFJhBfLPnS4SHKfpT5T 8yOeCgpo5aoIOBoG1+arjUNjUr6HwW63NTa94ljHwHr7CDkp7ofHhAMLuOrNSurjpFN+ 5yNUrSoLNSll/gycRhwrJXywmALkJzPyZJd/Sh76uCY9HAt66+JyyeOmquBa2wAQHpq9 axg2O1KOcpwKEZHaLiwOm1byYyPTjKJtnUIQPAm06ZLxaDY+MBFokk20UtRAyOtnuNSb WJRVlE00F0xraghge+SSzozloC572VXPo88y4e2bLMAiFu3Tk2Kfr+RPIKcXKGDnKsgE fbqQ== X-Received: by 10.194.158.34 with SMTP id wr2mr21088957wjb.23.1441491890641; Sat, 05 Sep 2015 15:24:50 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by smtp.gmail.com with ESMTPSA id c3sm11944261wja.3.2015.09.05.15.24.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Sep 2015 15:24:49 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] broken seamonkey :( Date: Sat, 5 Sep 2015 23:24:28 +0100 User-Agent: KMail/1.13.7 (Linux/4.0.5-gentoo; KDE/4.14.8; x86_64; ; ) References: <87oahjmg8s.fsf@heimdali.yagibdah.de> <201509051809.45420.michaelkintzios@gmail.com> In-Reply-To: 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: multipart/signed; boundary="nextPart2263024.ChDmkGcWms"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201509052324.43538.michaelkintzios@gmail.com> X-Archives-Salt: ae3313d5-8a65-4f07-b936-34db7e28c5cc X-Archives-Hash: a82fd919daf73487eb48a3545d472458 --nextPart2263024.ChDmkGcWms Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Saturday 05 Sep 2015 22:40:09 Fernando Rodriguez wrote: > On Saturday, September 05, 2015 6:09:36 PM Mick wrote: > > On Saturday 05 Sep 2015 14:06:27 lee wrote: > > > 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 >=20 > the >=20 > > > >> login-data on the phone and instruct to add an exception when the >=20 > dialog >=20 > > > >> to do so pops up when they are trying to connect. > > > >=20 > > > > 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 command will show two certs. The second is the CA. > > > >=20 > > > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-cer= ti > > > > fica te-authority/ > > >=20 > > > They're saying: > > >=20 > > >=20 > > > "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 > > > certificate will not validate correctly and you=E2=80=99ll get the = =E2=80=9Ccannot > > > verify > > > authenticity=E2=80=9D error." > > >=20 > > >=20 > > > 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? > >=20 > > If we are talking about changing subdomains, e.g. > > mailserver1.mydomain.com >=20 > and >=20 > > mailserver2.mydomain.com then you could use a wildcard CN field > > descriptor in your certificate: *.mydomain.com > >=20 > > If we are talking about a multidomain certificate, then you would have > > the main domain name in CN and add all the remaining domain names in the > > subjectAltName field. > >=20 > > For example: > >=20 > > [req] > > req_extensions =3D v3_req > >=20 > > [ v3_req ] > >=20 > > # Extensions to add to a certificate request > > [snip...] > >=20 > > subjectAltName =3D @alt_names > >=20 > > [alt_names] > > DNS.1 =3D mydomain.com > > DNS.2 =3D mydomain.net > > DNS.3 =3D www.mydomain.com > > DNS.4 =3D mx.sub.mydomain.com > > DNS.5 =3D mx.someotherdomain.com > > IP.1 =3D 123.456.78.9 > > IP.2 =3D 987.654.32.1 > >=20 > > You could specify the same on the CLI when you are generating the self >=20 > signed >=20 > > certificate. > >=20 > > > 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 th= at > > > seamonkey and relatives can be used to access email? > > >=20 > > > 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. > >=20 > > This I think is primarily a problem of the latest version of SeaMonkey.= =20 > > I suspect they have inadvertently added a regression bug. > >=20 > > > 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. > > >=20 > > >=20 > > > Well, I've made a bug report about this: > > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1202128 > >=20 > > Also have a look at this bug, in case it is related: > >=20 > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1036338 >=20 > Wildcards should do it. The browser will give you a warning but you don't > care since all you want is encryption and your users already trust you. >=20 > The only thing that matters about that article is that you'll be signing > your certificate with the CA ones so you get two certificates when you run > the openssl command, the last one is the CA certificate. If you, or your > users add trust to that one, anything you sign with it will be trusted. >=20 > I only tried it with a windows server issued certificate which does all > that by default. >=20 > Since it lets you open the exception dialog but just hangs when downloadi= ng > the certificate I wonder if it has something to do with your OCSP setting= s. > Check that they match mine: >=20 > security.OCSP.GET.enabled false > security.OCSP.enabled 1 > security.OCSP.require false >=20 > everything else is true. Some reports mention a couple of workarounds which may solve this problem: 1. Remove your certificate from *any* tabs that may have been saved in. Ch= eck=20 that it is no longer stored in any tab. Then try to reload it in the Authorities tab and see if it will allow you t= o=20 set up an exception. 2. I think you mentioned that you tried a fresh profile, but just in case: = =20 Make a back up of your Mozilla Profile. Go to Help/Troubleshooting and sel= ect=20 Refresh Firefox (or the equivalent for the SeaMonkey GUI). HTH. =2D-=20 Regards, Mick --nextPart2263024.ChDmkGcWms Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV62urAAoJELAdA+zwE4Ye98IH/3/CttNKldg/Rw2j72OZfq9H QAPZAUQ2/SVYWNY/VxjU6apY3QevNA53y+3TWuTnMybED56DtR5oRceUQvwSjvT5 tOz5l8CEOyQT4WUCf6iRMYvrdIoBXxMXzw6rJwGgiexWix/X+CzdsvtHKp24OffG lzns6Jzke4GDGjbvHuZz+WV15i06hBPDRdCDejhuIZO0nzgrF58pd7FcId6LQ8z4 9tQ7UTHJaN96bDB4Z0p6KQzkUGKDhQGksVGM2Au5y6z47LR+ApORj2rZxb2lmc3p HMdhKii4HisjpmRGClzDqzCsEILGdqe2P8kFMZDHy7caYunFN/RYpkUxh1FYEYk= =pVeb -----END PGP SIGNATURE----- --nextPart2263024.ChDmkGcWms--