Re: [gentoo-user] broken seamonkey :(

[lee]

Mick <michaelkintzios@×××××.com> writes:

> On Saturday 05 Sep 2015 14:06:27 lee wrote:
>> Fernando Rodriguez <frodriguez.developer@×××××××.com> 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 command 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’s an IP
>> address.  [...]  If it doesn’t match, even a properly signed certificate
>> will not validate correctly and you’ll get the “cannot verify
>> authenticity” 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?
>
> If we are talking about changing subdomains, e.g. mailserver1.mydomain.com and
> mailserver2.mydomain.com then you could use a wildcard CN field descriptor in
> your certificate:  *.mydomain.com

just different fqdns and IPs with which the server can be reached during
the lifetime of the certificate (which is only 10 years)

Can you foresee all possible fqdns and IPs it might have in the next 10
years?

I think it would be retarded to bind a certificate to a fqdn or IP. Both
can change at any time.  It's the certificate that counts and which can
be verified by a fingerprint before accepting it.  The host name and IP
are entirely irrelevant for this.  In some cases, you can even say that
the certificate is for an organization, not for a particular host or
device (operated by or being operated on behalf of the organization).


Or think of gpg: Binding a certificate to fqdn/IP would be like binding
my gpg public key to the place (like my postal address) I am at so that
I can decrypt something only when I happen to be at the right
place. Then give me an option to add multiple places to my pubkey when
creating it, and as soon as I'm at another place about which I haven't
foreseen that I might be there some time, I will have a problem.  For
all I know, I could be travelling in a car or a train or an air plane.

It's impractical.  Change is a constant.

> 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.
>
> For example:
>
> [req]
> req_extensions = v3_req
>
> [ v3_req ]
>
> # Extensions to add to a certificate request
> [snip...]
>
> subjectAltName = @alt_names
>
> [alt_names]
> DNS.1 = mydomain.com
> DNS.2 = mydomain.net
> DNS.3 = www.mydomain.com
> DNS.4 = mx.sub.mydomain.com
> DNS.5 = mx.someotherdomain.com
> IP.1 = 123.456.78.9
> IP.2 = 987.654.32.1
>
> You could specify the same on the CLI when you are generating the self signed
> certificate.

At least that's possible.  How would I add that without changing the
existing certificate?  I don't want to irritate the users, don't want to
have the phone calls about it and don't want trouble with the odd client
which happens to have been updated and refuses to accept the certificate
...

See what I mean?  It's impractical.

>> 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.
>
> This I think is primarily a problem of the latest version of SeaMonkey.  I
> suspect they have inadvertently added a regression bug.
>
>
>> 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=1202128
>
> Also have a look at this bug, in case it is related:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036338

I really can't tell.  It seems different in that even certificates that
were already used don't work anymore, which isn't the case here.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.