Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/le-test-01.example.com.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):
This was with .. run .. --cert-name .. -a apache -i null ...
And the choices for when using certonly:
1: Keep the existing certificate for now
2: Renew & replace the cert (may be subject to CA rate limits)
As said, --keep does have a function when there already exists the same cert and will prevent this question. I was merely trying to show you that even if a user runs a command without --keep twice, it wouldn't just magically issue a new cert without the user explicitely telling certbot to do so. It even clearly states possible consequences (rate limits).
Like I said, I'm just not an advocate of adding more and more command line options to prevent from users potentially doing a stupid thing. I'd like to advocate for users to understand what they are doing. I strongly believe people should never undertake any action they don't (fully) understand. Whether that's a choice made in an application of adding any option to the command line.
It occurs to me that although certbot is setting up a new Apache2 configuration on my development server, my router is still directing all port 80 traffic to the production server.
/etc/apache2/sites-enabled/000-default.conf (which the only one in there) has:
I have used https://sslforfree.com many times in the past. Last time I tried it it was in some kind of transition, but now it is working to generate ZeroSSL certificates, which are not free.
If you will be using HTTP authentication, then you will have to choose from:
run certbot on the production system
then copy the cert to the dev system
add a proxy to the production system so that the development system can hear the HTTP challenge requests and run certbot on dev
configure the router to send port 80 to the development system (and run certbot there)
configure the router to send port 80 to the development system (and run certbot there) and add a proxy to the dev system so that it only handles the challenge requests locally and forwards all other HTTP requests to the production system (presuming the production system needs some HTTP connections)
Yes - mail.davekimble.net
My mailserver system is evolving and has reached a stage where sometimes it has port 25 open, which is a potentially risky situation. Advice on what kind of attacks to expect would be welcome.
I'm not sure if that question is suitable for this Community. It's mainly meant for helping others with getting and/or installing a LE cert. Don't be surprised if you won't get an answer on this question.
If it responds to a port, expect that it will be scanned, pried, tested, attacked, etc.
As is the case with every open IP:port on the Internet. g305
The system is intended to work for 1 email address with Thunderbird on the LAN. It has 3 components, SMTP on :587, POP3 on :110 and MTA on :25. Developing software with :25 open to the WAN exposes it to scanning, spamming and attacks, so the MTA component is not always enabled/active. I agree that my question about what kind of attacks is not relevant to this forum, but if anyone has advice on which kind of attacks, it would be welcome.
It is written in PHP and all 3 components need about 400 lines of code, which is less than the poorly documented steering lines in Postfix's main.cf .
