.well-known directory deleted causing renew problem

[griffin]

@Rich64

CN="smoothgift.com,www.smoothgift.com"

Nope. That's the problem. To generate a SAN certificate you need a configuration file (with openssl at least).

[Rich64]

@_az

To get the information we're looking for, you can run:

openssl req -in /home/richard/pentaho-ssl/certreq.csr -noout -text

openssl req -in /home/richard/pentaho-ssl/certreq.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = NL, ST = Amsterdam, L = Amsterdam, O = Smoothgift, OU = smoothgift, CN = "smoothgift.com,www.smoothgift.com"
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit) .....

Or would you rather I post everything?

[griffin]

What is your first and last name? Common Name (CN)?
[Unknown]: smoothgift.com or www.smoothgift.com
What is the name of your organizational unit?
[Unknown]: Leave blank
What is the name of your organization?
[Unknown]: Smoothgift
What is the name of your City or Locality?
[Unknown]: Amsterdam
What is the name of your State or Province?
[Unknown]: Amsterdam
What is the two-letter country code for this unit?
[Unknown]: NL

Honestly, Let's Encrypt will discard all of these as unverifiable anyhow.

[_az]

Take a look at https://stackoverflow.com/a/43637750. The answer and comment show you how to use keytool in a way where you can add additional domain names to your CSR.

You can't jam them into CN, as @griffin has pointed out.

[griffin]

I think that's sufficient. The common name needs to be a single domain name.

[Rich64]

I have tried single domain name, with and without the www

[griffin]

Take a look at what _az posted.

[Rich64]

@_az

Take a look at certificate - How to create CSR with SANs using keytool - Stack Overflow. The answer and comment show you how to use keytool in a way where you can add additional domain names to your CSR.

You can't jam them into CN, as @griffin has pointed out.

According to the site, would this work then?:
keytool -certreq -file /home/richard/pentaho-ssl/certreq.csr -keystore /home/richard/pentaho-ssl/keystore
-alias smoothgiftAlias -ext SAN=dns:smoothgift.com,dns:www.smoothgift.com

[griffin]

keytool -certreq -file /home/richard/pentaho-ssl/certreq.csr -keystore /home/richard/pentaho-ssl/keystore
-alias smoothgiftAlias -ext SAN="dns:smoothgift.com,dns:www.smoothgift.com"

The CSR must contain the CN as either smoothgift.com or www.smoothgift.com, but not both.

[Rich64]

Just so these are clarified:

• redo keystore with CN=smoothgift.com or www.smoothgift.com, not both
• ignore your comment above to leave CN blank as Letsencrypt will ignore them anyway

[griffin]

I didn't think I said to leave CN blank. If I did, that's my mistake for sure. You need to specify the CN as one domain name or the other. You need to redo keystore with correct CN.

Fun fact: the CN is actually deprecated (obsolete). It is the SANs that matter. The CN is still required anyhow for now though.

Edit:

OMG! It asks for first and last name for the CN? That's definitely goofy! So that's where I messed up previously.

[Rich64]

I've reread your comment above and in fairness to you, you didn't say to ignore CN altogether. You said to use smoothgift.com or www.smoothgift.com. So, apologies, my bad!

So, redone the keystore, the csr and certonly certbot just the way the doctor prescribed and it worked!
Thanks! @griffin and @_az

I have the three certs! saved like /root/0001_chain.pem, etc to expire 2021-01-18.

Questions:

• As all previous certs and key are saved to /etc/certbot/live/smoothgift.com, do I have to move these new certs from /root/ to /etc/certbot/live/smoothgift.com which is actually symlinked to another directory somewhere? or leave the new certs at their present /root/ location and point applications to the certs new /root/ location?

• Preferably, I would like to have the new certs saved to /etc/certbot/live/smoothgift.com, how do I do that? run the command from /etc/certbot/live/smoothgift.com directory or how?

[rg305]

@Rich64

I have the three certs! saved like /root/0001_chain.pem

@Rich64

I would like to have the new certs saved to /etc/certbot/live/smoothgift.com

It is very unusual for certs to be paced into /root/.
Is there anything in the cli.ini file that would cause that?
Otherwise, look into using --cert-path with your next renewal.

[_az]

@rg305

It is very unusual for certs to be paced into /root/ .

The behavior of --csr is just to dump the certificates in the current working directory.

@rg305

Otherwise, look into using --cert-path with your next renewal.

Exactly the right thing to do, along with --fullchain-path.

[Rich64]

@rg305

@Rich64

I have the three certs! saved like /root/0001_chain.pem

@Rich64

I would like to have the new certs saved to /etc/certbot/live/smoothgift.com

It is very unusual for certs to be paced into /root/.
Is there anything in the cli.ini file that would cause that?
Otherwise, look into using --cert-path with your next renewal.

Yeah! And so is the file naming! Certbot's lost it!
Is there anything in the cli.ini file that would cause that? NO!
I tried to get Apache to use it but it wouldn't have it, said it's a mismatch with the private key. So, it is not usable!

[Rich64]

@_az

@rg305

It is very unusual for certs to be paced into /root/ .

The behavior of --csr is just to dump the certificates in the current working directory.

@rg305

Otherwise, look into using --cert-path with your next renewal.

Exactly the right thing to do, along with --fullchain-path.

Sorry but it wouldn't even come to that as it did not work. Flipping draining!
Could try with --fullchain-path but I doubt if anything will come out of that either. May be it would complain about renewal being too early...

[_az]

@Rich64

I tried to get Apache to use it but it wouldn't have it, said it's a mismatch with the private key. So, it is not usable!

If that's Apache's complaint, it's because you're not using the same private key that was used to generate that CSR.

Of course, Certbot has no idea where that private key is. Since you chose to use a CSR-based workflow, the location of the private key is known only to you.

Are you using Apache httpd or Apache Tomcat? Which private key did you point it at?

[Rich64]

@Rich64

I tried to get Apache to use it but it wouldn't have it, said it's a mismatch with the private key. So, it is not usable!

@_az

If that's Apache's complaint, it's because you're not using the same private key that was used to generate that CSR.

If I understand it right, the private key used to generate the CSR is in the keystore self signed certificate, how do you point certbot to use it in generating certonly?

@_az

Of course, Certbot has no idea where that private key is. Since you chose to use a CSR-based workflow, the location of the private key is known only to you.

Certbot should know by right, I reckon, since it installed one (private key) already and it's not being directed to use a different one somewhere. It has a config file with the needed info and just like --run, --certonly should use this info as well before generating certficates. And if it doesn't, and I do, the question is still, how do you point certbot to use it in generating certonly?

@_az

Are you using Apache httpd or Apache Tomcat? Which private key did you point it at?

Apache httpd. Letsencrypt's certbot private key in /etc/certbot/live/smoothgift.com/privkey.pem

[Rich64]

@_az

@rg305

It is very unusual for certs to be paced into /root/ .

The behavior of --csr is just to dump the certificates in the current working directory.

Ok, And if certbot is then run with --install option after or with the --csr option, could it be that certbot will then install them to the right folders?

[_az]

@Rich64

the private key used to generate the CSR is in the keystore

Yes.

@Rich64

how do you point certbot to use it in generating certonly?

You would need to export the private key from the keystore in PEM format (for example, like this) and then point Apache at the exported private key.

Notably, that private key is not the same one as /etc/certbot/live/smoothgift.com/privkey.pem.

Some other advice:

Just don't use --csr. There are very few situations where you should use it, and I don't think this is one of them. It doesn't support automated renewal and it is difficult to use.

I haven't read the earlier parts of this thread closely, but if this is about securing a Tomcat, the best advice is: don't configure Tomcat with SSL. Put a reverse proxy (e.g. Apache httpd) in front of it, and allow Certbot to configure httpd's SSL for you. No messing around with files.

If you decide to ignore that advice and configure Tomcat with SSL anyway, then the right workflow is this:

1. Create a renewable certificate with Certbot (using certonly but not with --csr).
2. Use a Certbot --deploy-hook to import the certificate and private key into the Tomcat keystore, then restart Tomcat.
3. Allow Certbot to automatically renew the certificate and invoke the deploy hook as is appropriate.

At the moment, you are doing things backwards, which makes things a lot more complicated:

1. You are starting with a Tomcat keystore containing a private key and self-signed certificate.
2. You are creating a CSR using the private key in the Tomcat keystore.
3. You are using the CSR to create a non-renewable certificate using certbot certonly --csr.
4. You now need to figure out how to also export the private key from the keystore so that Apache httpd can use it.
5. You now need to figure out how to script Certbot appropriately to recreate your certificate every X days, because --csr'd certificates do not automatically renew.

Again, I implore you to take the easy way out and allow Apache httpd and Certbot to do the heavy lifting.