Discussions on advancing X.509 usage

Development
1

I am an old-timer with X.509 and was active long ago in the IETF PKIX work. That said, it is sad how long it has taken X.509 to get more commonly used and how much old cruft is carried forward that was supposedly deprecated.

For example in

http://docs.nethserver.org/en/v7/base_system.html

it says:

To avoid problems while importing the certificate in Internet Explorer, the Common Name (CN) field should match the server FQDN.

This is wrong. CN was deprecated for subjectAltName (SAN). Of course openSSL command line does not support SAN, see

draft-moskowitz-ecdsa-pki sec 9.3

But it CAN and SHOULD be used. Minimally for ‘backwards compatibility’, CN and SAN should both occur.

Instead of single self-signed certs per server and service, what about a Nethserver installation pki? If not based on my drafts (for the ECDSA, Michael Richardson has pulled out all the scripts on my github

Hubert Kario hkario@redhat.com has on his github

And it has been a while, but I seem to recall that webmin had a pki feature (but it has been a few years since I used it).

What about CRL and OCSP? Client email certs. etc.

First step is what is the pki tree look like. What have you discussed here in the past. I did a search on x.509 and did not find any discussion on the subject (pun intended), but my search foo is known to be weak.

So please fill me in

1 Like
2

I think the most commonly-used solution at this point for server certificates is to get free trusted certs from Let’s Encrypt. That avoids the hassles commonly associated with self-signed certs (specifically, that clients don’t trust them). I don’t know what (if any) discussion has been had with respect to client certs, and am not sure how much use they’d be in most installations.

1 Like
3

For Let’s Encrypt certs, you have to be accessible via the Internet by them. Do most ADs get installed with Internet reachability?

How many certs/urls are there in a server?

  1. The admin (base url)
  2. The AD
  3. Roundcubemail
  4. DKIM
  5. Internal Cloud

Only DKIM and perhaps Roundcube needs external visibility. And there may be others. I have not looked at all the offering(s) here.

What are the cert needs? As a privacy proponent, I am not for putting multiple URLs in a single cert. It exposes more than is necessary. Particularly if some if it is internal use only.

Then there is offering client email certs for sender authentication. As for trust, Nethserver could offer a cross-certification service as part of subscription. I am the author of the Bridge CA model used by the US gov PKI and the BioPharma PKI. Others have picked up this approach rather than a large signing root with associated risks.

Of course, walking cross-certification trust chains (with potentially embedded policy) is challenging, the software is out there (e.g. Adobe has supported it for 15ys since BioPharma rolled out).

4

No, you don’t:
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_for_internal_servers
https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns

How does this use a cert or a URL? It uses a keypair, and the public key is published in a DNS record.

There isn’t necessarily a need to do so–you can either use a separate cert for each service, or put everything on a wildcard cert (or any combination of those you like). But any cert issued by any trusted CA is going to be listed in a public certificate transparency log, so if you get individual certs for your internal services, their names will still be public information.

This sounds more interesting–but wouldn’t it mean that Nethesis would need to act as a public CA?

1 Like