26 thoughts on - Certificates

• 31 aug 2018 kl. 19:47 skrev Chuck Campbell :

  Nope, you don’t have to pay for a certificate at one of the traditional CAs, you can use Let’s Encrypt to have free but fully valid certificates for your server.

  See https://letsencrypt.org/ for more information. I can recommend https://github.com/xenolf/lego for use on your server, but there are many different LE clients out there.

  If your phone does not already trust Let’s Encrypt’s CAs, you should be able to install their certificates to get it working. I suggest you start by getting a cert onto your server and take it from there though.

  Regards, Leo

• Leo,

  certbot works only with ports 80 or 443? Can lego work with with IMAP
  ports like 143 or 993? The documentation is not very clear.

  best regards
  –

• basically – independent of the client – letsencrypt will only support http/https or dns based challenges.

  so – if you want to get certificates for an imap only server, you will have to setup an webserver for the challenge. or deal with your dns server.

  best regards Ulf

• 31 aug 2018 kl. 21:31 skrev Michael Schumacher :

  I haven’t used certbot, only lego, but that’s not a problem.

  If you use leo you will have it manage the request for new and renewal of existing certificates. It does this using challenges over HTTP or DNS. I am guessing this is where your understanding that it only works with port 80 and 443 comes from – it uses either of those ports to communicate with Let’s Encrypt’s systems when using the HTTP challenge.

  However, this is separate from your IMAP server. Which ports your IMAP server use has nothing to do with lego or the LE certificate stuff. As long as something, e.g. lego, successfully manages to get valid certs onto your server, your IMAP server should be able to use those certificates (that is, a private key file and a public key file). Your IMAP server can use those files and may then respond to requests for IMAP over SSL/TLS on e.g. port 993. Port 143 is for unencrypted IMAP, so in that case certificates are not relevant at all.

  Consider trying leo out with the staging parameter enabled (see the documentation for it right there on the GitHub page), that way you can experiment with it and see what it produces and how it works. Then you can configure your IMAP server to use those certificate files.

  Regards, Leo

• 31 aug 2018 kl. 21:38 skrev Ulf Volmer :

  Setting up a web server is not needed – all you need is lego (which by the way is one statically linked binary since it’s written in Go).

  If you use the HTTP challenge, lego will temporarily, only for the time needed to fulfill the challenge, listen for HTTP on the relevant port.

  In summary, lego contains a web server for the HTTP challenge.

• At Fri, 31 Aug 2018 21:38:13 +0200 CentOS mailing list wrote:

  Yes, this works. I use mail.deepsoft.com for both imap and SquirrelMail and use the same cert for both SquirrelMail/Apache and dovecot.

• Letsencrypt.org has one other thing you should know about, not a biggie, the certificate is only good for 90 days at a time. Then you need to renew. But they though about that too, you can automate the renewal, so that each time the certificate expires and new one is generated and installed. It is supported by all of the major browsers, by supported, they are a part of the group that funds letsencrypt.org

  john

• Many large companies run their own CA and install their own root certificate.  Often installing a root cert is easier than installing a self-signed independent cert.  There is much written about building your own CA and a number of tools for that like openCA.  I can’t speak for all your devices or apps, but there should be ways….

  In personal promotion, I have been doing my own CA work for ECDSA certs and now for EDDSA certs (and I wonder what commercial CAs are providing them).  See my Internet draft:

  draft-moskowitz-ecdsa-pki

  And my github for pending updates to this and the new eddsa-pki draft
  (to be published after openSSL 1.1.1 is released).

  https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki https://github.com/rgmhtt/draft-moskowitz-eddsa-pki

  Or go to openCA or look at other CA toolkits available on CentOS and Fedora.

  Letsencrypt is a very important development, but it has (IMHO) a shaking foundation.  I would not build a production system around it.  But then I have lived in aspects of PKI since ’95…

• I presume you meant “shaky foundation”? If so, would you care to elaborate?

  John

• Yes.

• 1 sep 2018 kl. 00:42 skrev Robert Moskowitz :

  I’m not sure I still see the point you’re trying to make. What actual practical and concrete problems are you suggesting may arise in the situations you touch on above?

  As far as I know, if you have a properly set up LE certificate for a service, and renew it regularly, clients will not have a problem with this. They trust the root CA, and when you renew/replace the certificate, they will happily trust the new one, over and over again.

  Considering all relevant root trust stores now contain LE’s CA, it’s here to stay from what I can tell, not to mention it’s working well so far.

• Yes.

  [citation wanted]

  They’ll never notice regardless.

  I’m looking at a Google.com certificate right now that was generated on August 14th of this year and will not be valid past October 23. That’s the same replacement schedule as Let’s Encrypt.

  The old model of long-lived certificates has no special value. It’s purely a business decision on the part of the providers and customers. Automation removes much of this model’s value.

  Describe one.

  I’ve been running some of my domains on Let’s Encrypt for years now, and have never had a single user complain to me that my certs are changing too often.

  As long as both the old and new certs are valid at the time of replacement, the client should care nothing about it unless they’ve gone to the trouble to download the cert and check it against the cached copy every time.

  I remember hearing about at least one browser plugin that did this, but since the idea of rapid cert replacement has been gaining ground, I expect that plugin has lost much of the small amount of popularity it once held.

  There is now: it’s called Let’s Encrypt. :)

• in case of other then Webserver you use ACME-DNS
  just for a simple ACME client that is capable for ACME-DNS use acme.sh https//acme.sh/

• Having just setup up some LetsEncrypt certificates on a CentOS server:

  Certbot automates the process – if you have a webserver running, it will use that; if you don’t, it attaches a minimalistic web server to port 80 to respond to the LetsEncrypt challenges. It’s very, very easy.
  (The challenges are purely to verify that you are the owner of the domain you are asking for certificates for.)

  The certificates it generates can be used for IMAP and SMTP as well.

  certbot will automatically renew the certificates 2 weeks (I think)
  before they expire – it does not need the web/dns challenges for renewal. There are hooks in the process to put the renewed certificates wherever you want, otherwise it puts them where your web server is expecting them.

  P.

• Well, apart from STARTTLS …

  P.

• Why? I have corporate systems on 2 year commercial CA signed certificates and personal servers on 90 day LetsEncrypt ones – my users of IMAP and SMTP have never ever noticed when I changed the certificates on any device. They certificates all have trusted CAs so the clients trust them without any interaction. Even I don’t notice when certbot renews my certificates.

  The problem is one of trust – in the past even significant CAs have had their signing keys leaked, so it’s difficult for the root CAs to trust a company who deals with SMEs with cut price signing (the infrastructure has a significant cost, so they must be cutting corners somewhere!).

  That was until LetsEncrypt comes along – it has the backing of some big names and *IS* an effective business model for small and private customers.

  P.

• Am 01.09.2018 um 02:06 schrieb Warren Young :

  Out of curiosity – do you change also the private key every time?

  —
  LF

• What *is* the business model of Let’s Encrypt?

  Are they going to issue „Pro“ certificates at some point that cost money?

  Running a CA is not expensive per se – it’s the audits that the CAB (CA+Browser) Forum mandates that are expensive.

  In the beginning, the certificates had a certain level of trust with them that came both from the high prices (deterring drive-by crooks) and the fact that some sort of vetting was made to ensure that nobody could have issued a certificate for a domain they didn’t really control.

  But the later step is not very friendly to automation. And CAs can principally issue certificates for any domain – a fact brought home by the compromise of Dutch CA DigiNotar in the Fall 2011. Adding to the fact is a concentration-process in the industry that leads to fewer and fewer companies that know less and less of their customers.

  These days, a certificate just shows that the communication is encrypted. Whether the other endpoint is what it claims to be is of no concern to any third-party involved in setting up that communication-process.

  There’s even talk about deprecating the special handling browsers have for EV-certificates from future versions of Mozilla.

• I’m pretty sure LE creates a new private key, too. From a cursory glance at lego’s certificate directory on a server with a couple of dozens of LE certificates at least.

  After all, changing the private key is what this is all about (showing that you’re still in charge).

• I just checked on my box and confirm that yes, with every renewal of certificate new key is created. I should realize that fact even before looking, as it is asymmetric encryption pair, thus the new pair cert+key is generated (and the cert [request] gets signed).

  Valeri

  —
  ++++++++++++++++++++++++++++++++++++++++
  Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
  ++++++++++++++++++++++++++++++++++++++++

• Am 01.09.2018 um 20:27 schrieb Valeri Galtsev:

  You are commenting on a specific ACME helper tool to create LE
  certificates? On my side the key stays the same. And as long as it is not compromised there is no need to change it.

  Alexander

• when renewing a certificate the private key should also be changed;
  other ways the renewal because of short validity period doesn’t make a sense … depends on the implementation;

• They’re a nonprofit, run off of sponsorships and donations:

  https://letsencrypt.org/about/
  https://letsencrypt.org/donate/
  https://letsencrypt.org/docs/faq/
  https://letsencrypt.org/sponsors/
  https://letsencrypt.org/become-a-sponsor/

  That would be incompatible with their 501(c)(3) status.

  Indeed.

  Let’s Encrypt was inevitable: the compute costs of generating certs, running the back-end service, and holding the data were tiny in the 1990s and are even tinier now.

  Tiny times massive equals large, so at scale there are non-trivial costs, but the old standard of ~$100/yr was rapacious for what we’d now call a domain validation (DV) or light organization validation (OV) cert.

  I had certs in the early days, and even back then, a standard web site cert didn’t involve a whole lot of checking.

  That’s lead to the DV vs OV vs EV distinction:

  https://www.ssl.com/article/dv-ov-and-ev-certificates/

  If a DV-only cert is sufficient for your purposes, then Let’s Encrypt probably does all you need.

  The only reason to buy a cert these days is if you want OV or EV, and if it were me, I’d skip OV and go to EV in order to get the extra assurances that the green styling in the browser asserts. For some applications, it’s worth the money.

  DV-only covers a whole lot of use cases, though, including the one that started this thread.

  You may be right that there is little practical difference to a random end user between DV and OV, but I believe there is real value in EV.

  Why?

  I’m aware that it’s possible to generate a fraudulent EV cert, but to deprecate the distinction between EV and DV is to impugn the value of the CA system entirely. There’s plenty of problems in the system, which is one reason why we have the CAB Forum: untrustworthy CAs get run out of business.

  That leaves transparent TLS proxy middleboxes and such, but that’s just another “Who do you trust?” argument.

• On September 2, 2018 1:12:58 AM GMT+07:00, Rainer Duffner :

  It doesn’t hurt when the process is automated anyway but it’s by no means necessary. The limited validity period limits how long an attacker can abuse the cert they should get hold of it. However if you have no reason to suspect a compromise, it’s by no means necessary. It doesn’t improve security (if you’ve been hacked in a way you don’t notice, it’s highly likely the new key would leave your system the same way the previous one did) and it’s just one more thing that can go wrong of you so it manually.

  Cheers, Matthias

• I use something like this script to renew my SMTP and IMAP certificates
  (/etc/cron.weekly/certbot-renew):

  #!/bin/sh

  hostcert=/etc/letsencrypt/live/mail.example.com certlink=”$(readlink “${hostcert}/cert.pem”)”

  test -x /usr/bin/certbot || exit 72

  certbot certonly –quiet –standalone –keep-until-expiring \
      -d mail.example.com \
      -d imap.example.com \
      –email postmaster@example.com \
      –agree-tos –expand

  # Exit if the cert hasn’t been updated test “${certlink}” = “$(readlink “${hostcert}/cert.pem”)” && exit

  cat ${hostcert}/fullchain.pem ${hostcert}/privkey.pem >
  /usr/lib/courier/share/esmtpd.pem cat ${hostcert}/fullchain.pem ${hostcert}/privkey.pem >
  /usr/lib/courier/share/imapd.pem systemctl restart courier

• Mobile email

  Begin forwarded message: