Re: [gentoo-user] broken seamonkey :(

[lee]

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

> On Sunday 06 Sep 2015 03:45:26 lee wrote:
>> Mick <michaelkintzios@×××××.com> writes:
>> > On Saturday 05 Sep 2015 14:06:27 lee wrote:
>
>> >> 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?
>
> OK, 10 years is rather long for a common certificate.  In this case you should
> consider setting up your own CA key and CA certificate, with which you sign
> the server certificates.  Server certificates can expire and/or be revoked,
> you can update and publish a CRL, but the CA certificate will remain valid for
> 10 years.

I made it 10 years because you have to set a duration, and I didn't want
to be bothered with certificates expiring.  But I understand that I've
been doing it kinda wrong because it would have been better to make a CA
certificate which could be valid for a long time and sign certificates
with it which don't last that long.

Can I somehow deploy some sort of centralized infrastructure for clients
to automatically get the CA certificates from?  Otherwise, I would need
to import the CA certificate for every user manually.

> [...]
>
>> 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
> [...]
>
> Sure, but (although you could) gpg is not usually used to secure the
> connection to a server.  A server's identity is interlinked with its domain
> name, or IP address.  The identity for gpg is linked to the email address of
> its owner.  You wouldn't sign/encrypt your work's email with the gpg key for
> your private email address.

With gpg, the linkage to an email address was introduced a long time ago
to make it easy to determine from an email address which key to use.
Back then, people usually did have no more than one email address,
perhaps another one at their work place, and most people didn't have any
email addresses at all.

That has changed.  However, even back then, the email address wasn't
used to identify a person.  You could only know that, with a great deal
of likelyness, an email --- sent from whatever email address --- was
sent by a particular person when it was signed or encrypted with the key
you definitely knew was that particular person's key.

That has *not* changed.  The same principle applies to certificates.

So what sense does it make for a certificate to be linked to an FQDN or
IP?  None of those necessarily identify a particular server.  If they
did, the only purpose of certificates would be to assist encryption, and
they wouldn't have anything to do with identification. --- You're using
gmail (which I won't because of privacy concerns):  Can you be sure that
you connect to the same server every time you receive or send your
emails?  You probably don't.

The underlying idea is trust.  If you trust a CA --- and I don't see any
particular reason to trust any of the CAs seamonkey knows by default and
most, if not all of which, I've never even heard about --- a certificate
signed by it is accepted without asking you.

Is that good or bad?  Back then, when I used gpg, I had my key signed by
people I met personally and signed theirs.  We would know by the fact
that the key was used, not by any particular email address.

So the identity for gpg is *not* linked to the email address of its
owner. Nobody prevents you from encrypting or signing an email with your
key and sending it from an arbitrary email address.  Recipients may only
conclude that it was you who sent the email by verifying that your key
was used, and first they have to trust that this key is actually yours.
You may need to explicitly specify the key-ID or an email address to
tell gpg which key to use when you do that.

Same goes for certificates, and there's no point in linking them to
FQDNs/IPs.  If they are linked for the practical reason to figure out
which certificate to use, like gpg can use an email address to figure
out which key to use, then I'd say that a better way needs to be found
to do that.  Similar to a key-ID specific to a key, certificates could
have a certificate-ID --- perhaps they already do.

>> > 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.
>
> Yes. It could be impractical at this stage, because the architecture of your
> PKI has to change.
>
> However, you can treat your existent self-signed certificate as a CA and use
> it to sign other certificates which contain different IP addresses, fqdns,
> etc. depending on the server(s) in question.
>
> If your clients have accepted your self-signed certificate as a CA, then it
> should not cause a problem.

When I look at one of the CA certificates seamonkey shows me, I don't
see any specific FQDN or IP involved.  Am I to understand that a CA
certificate is like what I kinda wanted in the first place, i. e. something
like a certificate which identifies an organization (rather than a
device operated by the organization)?  And that the CA certificate can
be used (by the organization) to, well, certify that a particular device
it operates is operated by the organisation by creating a certificate
for the device and signing it with the CA certificate?

If that is so, then why should I need or use one certificate for each
device --- or for each service?  I'm certifying myself that this is the
particular organisation and that everything is fine, one way or
another. So far, the true and only purpose of these certificates is to
assist encryption.  Unless I am able to give users, in a secure way,
some means of verifying that a certificate they accept is actually from
the organization, the certificates cannot be used for identification
anyway.


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