acme _ecc

Now that acme has changed it's default certs to use ECC (Elliptic Curve Cryptography) Certificates how do we update older ispconfig servers all to use _ecc folders (with postfix and dovecot). Some still use /root.acme/fqdn without _ecc in folder name. Can we just remove the old folders and generate new ones?

Will this dovecot config break...

Code:

ssl_cert = </etc/postfix/smtpd.cert
ssl_key = </etc/postfix/smtpd.key
ssl_dh = </etc/dovecot/dh.pem

Will ispconfig use acme dh.pem file? What about Dovecot /private folder links?

 

So if I want to bring all servers "up to date" so all of them have the same logic all I have to do is remove the old folders in /root.acme/ and Ispconfig will generate new ones with _ecc structure?

 

Just a stupid question here — @SamTzu when you mention "remove the old folders", what exactly do you mean by "old folders"? Only those that do not end in _ecc? Or all of them? And will ISPConfig3 automatically handle the symlinks to the "old" directories (i.e., those without _ecc at the end), or put them all into the non-_ecc-terminated directories instead?

Sorry, I've been struggling for the past two years or so in "getting this right"... and still haven't!

See also https://forum.howtoforge.com/threads/acme-sh-ecc-sufix.90093/

 

I am not using acme.me/sh yet, but I think yes new ones are with ecc extension, automatically if I remember correctly, so old ones can be deleted. In certbot, the method is still symlink but only to live folder of /etc/letsencrypt, which symlink to the latest ones in archives, so older ones can also be safely deleted too, though we need not to because our LE files are lesser compared to copy and output to new folder like acme.sh, which will have two copies all the times, ones in it and ones in each SSL folder for website and ISPConfig.

 

@ahrasis you managed to totally confuse me

My own configuration is an absolute mess: each site/domain has its own weird logic.

The earliest ones (pre-Let's Encrypt) have symlinks from /var/www/example.com/ssl/example.com.crt directly to /var/www/example.com/ssl/example.com-le.crt ... which, in turn, just link to /etc/letsencrypt/example.com/example.com.cer — while, on a few old examples, /etc/letsencrypt/example.com/ is just a symlink to /etc/letsencrypt/example.com_ecc/.

Then, for a while, I had everything under /etc/letsencrypt/example.com/ — and under /var/www/example.com/ssl I placed "new" symlinks to there, in case any old configurations were still looking for the certificates under /var/www/example.com/ssl/. This was the case, for instance, with postfix, dovecot, etc.

When ECC came out, of course, this required another level of symlinks Again, this is not consistent: on the more recent cases, Let's Encrypt only generated the ECC keys/certs, so, the names remained unchanged (i.e., no extra _ecc on the directories, no -le on the filenames, etc.). This is quite close to how ISPConfig worked in the pre-Let's Encrypt era!

Now, I'm not quite sure what I have. Thanks to acme.sh's copy feature, I believe that, in many cases, I just have duplicated keys and certs, both under /etc/letsencrypt/example.com/ and /var/www/example.com/ssl/, just with different names (LE has a convention, ISPConfig3 another, so the filenames are different, but the contents are the same!). This, of course, makes my mind blow as I'm never sure which certificates are current, which have been automatically updated, which are still waiting, etc. Every now and then, the 'wrong' key will show up on the server. This is especially troublesome in two cases:
- Because I use DANE for the SMTP mail service, I suffer from the issues with the keys that are not properly rotated in time, and automatically updated on my DNS service (I use Cloudflare for almost all cases).
- I have three "mysterious" exceptional cases that will "disappear" every month. I don't know how or why that happens — except that it's related to the multiple-layers-of-symlinks hierarchy. Some of those are very old domains. Some are very new. Some have plenty of aliases; and some are just a single subdomain. Why exactly "only" these three are affected and no others is beyond my understanding!

What I really, really, really wished to do is to revert back to the "old" days...

1. Have everything under /var/www/example.com/ssl with the old names (example.com.crt, example.com.key, fullchain.cer).
2. Have all configurations (web, mail...) grab the certificates from /var/www/example.com/ssl with the "correct" names, so that all procedures and checks are fully automated.
3. Let's Encrypt can be wherever it wishes to be — I don't mind, so long as I know where the certs are!
4. Similarly, acme.sh can be installed anywhere as well, so long as it knows:
   1. Where Let's Encrypt stores the certificates; and
   2. Where ISPConfig3 (i.e., everything managed by it, such as web, email...) expects the certificates to be.

Ideally, I would prefer to avoid running acme.sh from the root user's directory, but that's just a question of personal preference.
So why don't I do "just that"?...
Well, my problem is not the ISPConfig3-managed services. Those, in general, have no problems! No, my problem is that I have several other services which are not managed by ISPConfig3 — except for the actual "hosting space", so to speak — but they nevertheless require SSL/TLS certificates to run — and need to know where these can be found.
A few examples: a streaming server, a FreeSwitch server, a document management system, a whole 3D virtual world environment... etc. All of these are autonomous — they're not PHP scripts! — and most don't even use nginx. There are a few exceptions, where nginx serves the static files while the application manages the dynamic content — in fact, pretty much the same setup as the nginx/PHP combination! — as well as small services that run as FastCGI applications, because they don't truly need to be "always on" and waste extra ports.
Almost all of these have their own configuration, of course, but each uses a different way of getting configured. And, of course, over the years, each 'expects' their certificates to be... somewhere. Sometimes this is "anywhere but not under /var/www/example.com/ssl" for some stupid reason. Thus, symlinks to the rescue!
Oh well. If and when I have time, I'll be going through all configured sites and services, one by one, and settle on one single configuration — most likely, under /var/www/example.com/ssl, because that's how it makes more sense to me: each domain is a mini-container with all relevant information (including logs and certificates...). But that's far away in the future for me...

 

To me, your explanation doesn't make sense at all because acme.sh had never symlinked but has since the beginning used its copy function instead. If you said the certs were symlinked, that was because they were created using certbot, not acme.sh to begin with. Script acme.sh had never used /etc/letsencrypt/ as its certs folder before, but at ~/.acme.sh/domain.tld, always, as far as my memory serves me well.

My thinking now, double check if you are using both, and if so, remove acme.sh since you use symlink a lot and are used to it. Also ensure that your certbot is the latest, and there is only one version of it, either apt or snap, but not multiple certbot. Some might even have the old certbot-auto if not properly cleaned up.

We talk about more on what to do when you have confirmed you use only one, because newest certs will always be issued with ecc, structured by ISPConfig, to differentiate and work with the older ones, that are without it. Please for your own sake, do not change those manually, because it will confuse you more, not solving nor helping.