Subdomains Not In Certs

My domain is: https://icf.quantum-equities.com/

I ran this command: certbot certonly --standalone --agree-tos --email colony.three@protonmail.ch --renew-by-default --domains quantum-equities.com --reuse-key --keep

It produced this output: Success

My web server is (include version): Apache 2.4.34 8.el7.1

The operating system my web server runs on is (include version): CentOS 7.4

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.0.0

I can’t seem to successfully ass a subdomain to the domain’s cert. I added DNS.2 = icf.quantum-equities.com to csr-quantum-equities.com.conf and ran the above command, but it’s still not recognized.

1 Like

Hi @Quantum

add your subdomain to your command.

-d icf.quantum-equities.com.

2 Likes

Ah, so should I include that also in my periodic renewals?

Why does that work when re-using keys?

Why did it not work for carl.unofficial-tesla-tech.com ? (after restarting httpd24-httpd)

Anyone here? Tried IRC but it’s dead now.

Can you use "certbot renew" to renew your certificates? It uses Certbot's stored information so you don't have to specify any other options.

What's csr-quantum-equities.com.conf? The command above didn't make reference to it.

Edit:

Maybe you were using a custom CSR so that you could reuse the same private key before Certbot added the --reuse-key option. But it doesn't look like you're using one now.

What was the rest of Certbot's output?

What does "certbot certificates" output?

1 Like

certbot certonly --standalone --agree-tos --email colony.three@protonmail.ch --renew-by-default --domains unofficial-tesla-tech.com -d carl.unofficial-tesla-tech.com --reuse-key --keep

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/unofficial-tesla-tech.com-0001/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/unofficial-tesla-tech.com-0001/privkey.pem
    Your cert will expire on 2020-05-13. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    “certbot renew”

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

It looks like the problem stems from my trying to get rid of the -001 directory. I have the Apache virtual host pointed to the non-001 directory which is not getting updated with the new subdomain.

I’ve deleted -001 in live, archive, and renewal, but still when I issue the command as above it re-creates the -001 directory. I do not understand this.

As to my update method, I come from a time when this was how you did it. Maybe the cool kids are using some newfangled way now, and if so I need complete detail on what goes in to my script, as what I have works reliably and without fail.

Anyone know how to eliminate the -001 directory?

Please read the documentation:

https://certbot.eff.org/docs/using.html#certbot-command-line-options

But that isn't a real problem.

That's

bad, you may hit the limit.

1 Like

Ok, --cert-path, --key-path, --fullchain-path, -chain-path.

But this still does not answer my main question: When I add these new options to the certbot command-line (-d to add a subdomain)… is that then persistent? Do I have to modify my update script with these new options?

The renewal subdir is supposed to preserve the last update, but even though I deleted the -001 conf file, when I ran the certbot command it spookily re-created it, ignoring the non-001 conf file for some reason. What was the source of this insolence?

And why when I simply refresh a key, would it count against my renewal numbers? When I run out am I banned forever? Just a year? Because I’m unable to get this configured?

Please read the documentation:

In the case of a name collision it will append a number like 0001 to the file path name.

So use --cert-name to overwrite an existing certificate if you don't want that.

But it's not relevant, because a cert is a cert. The name of the folder isn't important.

1 Like

I have a million things to do and no time to do them, and still don’t have a solution. Many of my questions above are unanswered.

Never mind. I don’t have time for this.

Certbot will remember your -d options when you use certbot renew. Most options are stored in an associated file in /etc/letsencrypt/renewal, while the domain names to be requested are taken from the domain coverage of the pre-existing certificate itself.

If the names you requested with -d overlap with the names on an old certificate, but aren't a strict superset of them, and you didn't specify --cert-name, Certbot creates a new certificate with a number if necessary.

The general rule is that Certbot creates a certificate with all of the domains that you mentioned in -d when you ran Certbot, and no others. If you want to add new domains, you also have to re-list the old domains. If you want to replace the existing Certbot-managed certificate, you have to list everything that it contained with no exceptions, or else use --cert-name to force Certbot to save the new certificate with a specific certificate name.

Certificate renewal is implemented as a new certificate issuance from the CA. Renewal requests are implemented as a new certificate request. Both of these actions use some CA resources and are subject to rate limits. The specific rate limits depend on exactly what you do and what resources you use, but the two most common last for one hour (in case of excessive unsuccessful requests) or seven days (in the case of excessive successful requests).

1 Like

Thank you Schoen.

I set up my system in early days when alot of things didn’t work quite right. But my methods work flawlessly.

  • Is it still necessary to turn off selinux before cert renewal?

  • Does the python2-certbot-apache plugin work to allow certbot renewal without shutting down Apache? Even for SCL’s httpd24-httpd? (which I must use for MediaWiki)

  • With certbot-renew is there some mechanism for emailing me when a request for a given domain fails?

  • Can I get away with turning off all elliptic curve algos and still be compatible with most browsers?

1 Like

Is it still necessary to turn off selinux before cert renewal?

I don't know; that depends on what restrictions selinux is applying.

Does the python2-certbot-apache plugin work to allow certbot renewal without shutting down Apache? Even for SCL’s httpd24-httpd? (which I must use for MediaWiki)

Yes, although remember that Python 2 is EOL.

With certbot-renew is there some mechanism for emailing me when a request for a given domain fails?

If you run certbot renew -q you should only get output in case of problems, so if you're running from cron, you could get cron e-mail when this output is present, for example.

Can I get away with turning off all elliptic curve algos and still be compatible with most browsers?

I think so, but the details are complicated. You could try making the change and then testing your site on SSL Labs, which will simulate compatibility with various browsers.

1 Like

Oh dear, I hadn't noticed that. Actually I'm running python 7.2 there. What is the mechanism that certbot uses with --renew to run while Apache is running?

My current method for testing success is:
if [ ! -f ${FULLCHAIN} -o ! -f ${CHAIN} -o ! -f ${CERT} ]; then
cat ${OUT} | mail -s "TLS Cert Update Fail for delphi-real-estate.com" postmaster@delphi-real-estate.com
fi

What would I test for and what variable could I set for the failed domain with -q?

1 Like

It edits the Apache configuration files and then uses apachectl graceful to do a "graceful" restart that doesn't interrupt active connections.

certbot renew is meant to be run frequently and it doesn't attempt to do renewals except of certificates that are near expiry. My recollection is that it returns exit status 0 if no renewals were attempted or if the renewals that were attempted succeeded, and exit status 1 if one or more attempted renewals failed. So you might be able to test the exit status, like if ! certbot renew -q; then in order to detect this case.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.