[GTALUG] SSL Certs for both web and email servers

[Giles Orr]

On Thu, 3 Dec 2020 at 14:14, William Witteman via talk <talk at gtalug.org> wrote:
>
> Thanks for your help!
>
> I have not yet set the redirects from http -> https, but the result
> was achieved *much* more easily than I would have expected.
>
> I have an existing cert that I set up as a standalone, which dovecot
> has been using happily for a few years.  I did not know that I could
> expand what that cert covers, but the good people at EFF have made
> this very easy.
>
> I used this command and it Just Worked(TM):
>
> sudo certbot -d
> comma,separated,list,of,each,domain,and,subdomain,including,the,ones,already,in,place
> --expand
>
> And after a moment, all of my domains and subdomains are under the
> single umbrella that I already had.
>
> Note that the above list includes three different domains and a half
> dozen subdomains, all of which seem to just work now.
>
> Thanks again!

Heh - you top-posted, and I'm too lazy to fix the sequencing so now we
have mixed post order ... oh well!

If you're new to 'certbot' I recommend that you watch very closely as
you approach the three month mark.  Let's Encrypt's certs are only for
three months.  But if you've installed it on Debian, you should also
find that you have a twice-daily cron job that attempts to renew all
issued certificates automatically.  It will fail silently up until the
two month mark (don't quote me on this, I think it's two months), and
then just as quietly renew and replace the certs when it does.  It's a
lovely system, but you'll want to check maybe two weeks before they
need renewal.  If they haven't renewed automatically you'll need to
take a closer look at your system(s) to see what went wrong.

I wrote a shell script that takes a list of domain names as input,
then grabs the certificate for each domain and lists the names and
expiries for each.  It uses the 'openssl' command to extract the
expiry date, and a bit of date magic to determine if any are expiring
in less than a month and then highlights those.  I run it weekly
against my business's sites (that list is programmatically generated
too), and it's saved my ass a few times ...

> On Tue, 1 Dec 2020 at 06:37, ac via talk <talk at gtalug.org> wrote:
> >
> > On Tue, 1 Dec 2020 03:34:06 -0500
> > John Sellens via talk <talk at gtalug.org> wrote:
> > > On Tue, 2020/12/01 08:16:49AM +0200, ac via talk <talk at gtalug.org>
> > > wrote: | > I have three domains and a small but invariant number of
> > > subdomains | > that I want to encrypt - should I try to pull them all
> > > under one SSL | > cert, or do one for each domain, or one for every
> > > subdomain?  I don't | > need a wildcard, but I would like something
> > > relatively painless if | > possible.
> > > |
> > > | yes, in your case, and for painless and easy, just use the domain
> > > name | and one cert. so, instead of mail.example.com and
> > > www.example.com | - just use example.com.
> > >
> > > I think that might cause client complaints in some cases.
> > >
> > imho i do not think with three domains this will be an issue.
> >
> > what is the point of having mail.example.com if the IP number for
> > mail.example.com is the same as example.com ? the same can be asked
> > about imap.example.com and pop.example.com etc.
> >
> > This is just wasteful and increases the risk of issues, ads complexity
> > and does not serve any "real" technical, logical or functional purpose.
> >
> > The reason why mail.example.com used to be prevalent - pre container -
> > was because mail.example.com - was at a different IP number / different network
> > even...
> >
> > And, actually even if you had 100 domains on one server: reducing
> > complexity, reducing the amount of DNS lookups and reducing pebcac,
> > reducing comms, reducing traffic, reducing load and reducing wastage -
> > means:
> >
> > You are making it easier for clients
> >
> > And : You are even saving cycles, saving electricity, saving network
> > traffic and TOOOTEROOO:
> >
> > Saving the planet
> >
> > in case you did not know: In 2020 - 2030 - we will still get the vast
> > majority of our power from non sustainable fossil sources. so, we
> > should all try to be less wasteful, mind you, now with Alaska being
> > strip mined and auction sold, the planet has a lot more to waste.
> >
> > > I think letsencrypt now provides wildcard certifications, but you
> > > can use mutliple -d options when creating or updating a certificate
> > > e.g.
> > >
> > >   certbot certonly \
> > >     --non-interactive \
> > >     --expand \
> > >     --webroot \
> > >     -w /var/www/html/letsencrypt \
> > >     --cert-name www.example.com \
> > >     -d example.com \
> > >     -d mail.example.com \
> > >     -d blog.example.com
> > > And then the one certificate is valid for all those names.
> > >
> > a small number of invariant sub domains usually means
> > www.example.com, pop.example.com, mail.example.com,
> > imap.example.com and in this case - x3 domains
> >
> > but, one could also wildcard (*) just simply -d *.example.com and add
> > _acme-challenge TXT record to example.com dns zone
> > (auth: preferred-challenges=dns - when you apply for cert)
> >
> > depending on your resources and very importantly, your dns servers
> > timeouts, rate_limits and other issues, there could be pain/risk with
> > multiple/many -d every 90 days
> >
> > > Hope that helps - letsencrypt is really remarkably convenient.
> > >
> > indeed it is.

-- 
Giles
https://www.gilesorr.com/
gilesorr at gmail.com