Cpanel certificate installation failed with cert obtained using getssl

yes, this is what i did that led to getssl not writing the crt files

3 Likes

@timkimber

This is incorrect:

# Production options are: "ISRG Root X1" and "ISRG Root X2"

It should be:

# Production options are: "DST Root CA X3" and "ISRG Root X1"

One cannot choose ISRG Root X2 because it is for ECDSA issuance only and will automatically apply through issuance via the E1 intermediate certificate if and only if the signature type in the CSR is ECDSA and the associated ACME account is on the ECDSA allow list. There is only a default chain of (leaf, E1, ISRG Root X2) for ECDSA issuance.


This is questionable:

The SAN set in a certificate (or certificate signing request (CSR)) must include the common name (CN), which is itself obsolete.

3 Likes

i did this and got the same result (no crt files written). Unfortunately the getssl script is not printing anything to the console in this case. i ran with the -d option and didn't see any indication that there would be a problem.

ancestry@ancestryweb.org [~/getssl]# ./getssl -d

detected os type = linux

checking for required which ... /usr/bin/which

checking for required openssl ... /usr/bin/openssl

checking for required curl ... /usr/bin/curl

checking for dig ... /usr/bin/dig

function dig found at /usr/bin/dig  - setting DNS_CHECK_FUNC to dig

checking for required dirname ... /usr/bin/dirname

checking for required awk ... /bin/awk

checking for required tr ... /usr/bin/tr

checking for required date ... /bin/date

checking for required grep ... /bin/grep

checking for required sed ... /bin/sed

checking for required sort ... /bin/sort

checking for required mktemp ... /bin/mktemp

current code is version 2.41

Most recent version is  2.41
2 Likes

@stephening

Please post both your top level and domain level configuration files again. I want to ensure that we're on the same page.

3 Likes

Top level:

# vim: filetype=sh
#
# This file is read first and is common to all domains
#
# Uncomment and modify any variables you need
# see https://github.com/srvrco/getssl/wiki/Config-variables for details
#
# The staging server is best for testing (hence set as default)
#CA="https://acme-staging-v02.api.letsencrypt.org"
# This server issues full certificates, however has rate limits
CA="https://acme-v02.api.letsencrypt.org"

# The agreement that must be signed with the CA, if not defined the default agreement will be used
#AGREEMENT=""

# Set an email address associated with your account - generally set at account level rather than domain.
#ACCOUNT_EMAIL="me@example.com"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/home/ancestry/.getssl/account.key"

# Account key and private key types - can be rsa, prime256v1, secp384r1 or secp521r1
#ACCOUNT_KEY_TYPE="rsa"
PRIVATE_KEY_ALG="rsa"
#REUSE_PRIVATE_KEY="true"

# Preferred Chain - use an different certificate root from the default
# This uses wildcard matching so requesting "X1" returns the correct certificate - may need to escape characters
# Staging options are: "(STAGING) Doctored Durian Root CA X3" and "(STAGING) Pretend Pear X1"
# Production options are: "ISRG Root X1" and "ISRG Root X2"
#PREFERRED_CHAIN="\(STAGING\) Pretend Pear X1"

# Uncomment this if you need the full chain file to include the root certificate (Java keystores, Nutanix Prism)
#FULL_CHAIN_INCLUDE_ROOT="true"

# The command needed to reload apache / nginx or whatever you use.
# Several (ssh) commands may be given using a bash array:
# RELOAD_CMD=('ssh:sshuserid@server5:systemctl reload httpd' 'logger getssl for server5 efficient.')
#RELOAD_CMD=""

# The time period within which you want to allow renewal of a certificate
#  this prevents hitting some of the rate limits.
# Creating a file called FORCE_RENEWAL in the domain directory allows one-off overrides
# of this setting
RENEW_ALLOW="30"

# Define the server type. This can be https, ftp, ftpi, imap, imaps, pop3, pop3s, smtp,
# smtps_deprecated, smtps, smtp_submission, xmpp, xmpps, ldaps or a port number which
# will be checked for certificate expiry and also will be checked after
# an update to confirm correct certificate is running (if CHECK_REMOTE) is set to true
SERVER_TYPE="https"
CHECK_REMOTE="true"

# Use the following 3 variables if you want to validate via DNS
#VALIDATE_VIA_DNS="true"
#DNS_ADD_COMMAND=
#DNS_DEL_COMMAND=

# Unusual configurations (especially split views) may require these.
# If you have a mixture, these can go in the per-domain getssl.cfg.
#
# If you must use an external DNS Server (e.g. due to split views)
# Specify it here.  Otherwise, the default is to find the zone master.
# The default will usually work.
# PUBLIC_DNS_SERVER="8.8.8.8"

# If getssl is unable to determine the authoritative nameserver for a domain
# it will as you to enter AUTH_DNS_SERVER.  This is a server that
# can answer queries for the zone - a master or a slave, not a recursive server.
# AUTH_DNS_SERVER="10.0.0.14"

Domain level:

# vim: filetype=sh
#
# This file is read second (and per domain if running with the -a option)
# and overwrites any settings from the first file
#
# Uncomment and modify any variables you need
# see https://github.com/srvrco/getssl/wiki/Config-variables for details
# see https://github.com/srvrco/getssl/wiki/Example-config-files for example configs
#
# The staging server is best for testing
#CA="https://acme-staging-v02.api.letsencrypt.org"
# This server issues full certificates, however has rate limits
CA="https://acme-v02.api.letsencrypt.org"

# Private key types - can be rsa, prime256v1, secp384r1 or secp521r1
#PRIVATE_KEY_ALG="rsa"

# Additional domains - this could be multiple domains / subdomains in a comma separated list
# Note: this is Additional domains - so should not include the primary domain.
SANS=""

# Acme Challenge Location. The first line for the domain, the following ones for each additional domain.
# If these start with ssh: then the next variable is assumed to be the hostname and the rest the location.
# An ssh key will be needed to provide you with access to the remote server.
# Optionally, you can specify a different userid for ssh/scp to use on the remote server before the @ sign.
# If left blank, the username on the local server will be used to authenticate against the remote server.
# If these start with ftp:/ftpes:/ftps: then the next variables are ftpuserid:ftppassword:servername:ACL_location
# These should be of the form "/path/to/your/website/folder/.well-known/acme-challenge"
# where "/path/to/your/website/folder/" is the path, on your web server, to the web root for your domain.
# ftp: uses regular ftp; ftpes: ftp over explicit TLS (port 21); ftps: ftp over implicit TLS (port 990).
# ftps/ftpes support FTPS_OPTIONS, e.g. to add "--insecure" to the curl command for hosts with self-signed certificates.
# You can also user WebDAV over HTTPS as transport mechanism. To do so, start with davs: followed by username,
# password, host, port (explicitly needed even if using default port 443) and path on the server.
# Multiple locations can be defined for a file by separating the locations with a semi-colon.
ACL=('/home/ancestry/public_html/.well-known/acme-challenge')
#ACL=('/var/www/ancestryweb.org/web/.well-known/acme-challenge'
#     'ssh:server5:/var/www/ancestryweb.org/web/.well-known/acme-challenge'
#     'ssh:sshuserid@server5:/var/www/ancestryweb.org/web/.well-known/acme-challenge'
#     'ftp:ftpuserid:ftppassword:ancestryweb.org:/web/.well-known/acme-challenge'
#     'davs:davsuserid:davspassword:{DOMAIN}:443:/web/.well-known/acme-challenge'
#     'ftps:ftpuserid:ftppassword:ancestryweb.org:/web/.well-known/acme-challenge'
#     'ftpes:ftpuserid:ftppassword:ancestryweb.org:/web/.well-known/acme-challenge')

# Specify SSH options, e.g. non standard port in SSH_OPTS
# (Can also use SCP_OPTS and SFTP_OPTS)
# SSH_OPTS=-p 12345

# Set USE_SINGLE_ACL="true" to use a single ACL for all checks
#USE_SINGLE_ACL="false"

# Preferred Chain - use an different certificate root from the default
# This uses wildcard matching so requesting "X1" returns the correct certificate - may need to escape characters
# Staging options are: "(STAGING) Doctored Durian Root CA X3" and "(STAGING) Pretend Pear X1"
# Production options are: "ISRG Root X1" and "ISRG Root X2"
#PREFERRED_CHAIN="\(STAGING\) Pretend Pear X1"

# Uncomment this if you need the full chain file to include the root certificate (Java keystores, Nutanix Prism)
#FULL_CHAIN_INCLUDE_ROOT="true"

# Location for all your certs, these can either be on the server (full path name)
# or using ssh /sftp as for the ACL
#DOMAIN_CERT_LOCATION="/etc/ssl/ancestryweb.org.crt" # this is domain cert
#DOMAIN_KEY_LOCATION="/etc/ssl/ancestryweb.org.key" # this is domain key
#CA_CERT_LOCATION="/etc/ssl/chain.crt" # this is CA cert
#DOMAIN_CHAIN_LOCATION="" # this is the domain cert and CA cert
#DOMAIN_PEM_LOCATION="" # this is the domain key, domain cert and CA cert

# The command needed to reload apache / nginx or whatever you use.
# Several (ssh) commands may be given using a bash array:
# RELOAD_CMD=('ssh:sshuserid@server5:systemctl reload httpd' 'logger getssl for server5 efficient.')
#RELOAD_CMD=""

# Uncomment the following line to prevent non-interactive renewals of certificates
#PREVENT_NON_INTERACTIVE_RENEWAL="true"

# Define the server type. This can be https, ftp, ftpi, imap, imaps, pop3, pop3s, smtp,
# smtps_deprecated, smtps, smtp_submission, xmpp, xmpps, ldaps or a port number which
# will be checked for certificate expiry and also will be checked after
# an update to confirm correct certificate is running (if CHECK_REMOTE) is set to true
#SERVER_TYPE="https"
#CHECK_REMOTE="true"
#CHECK_REMOTE_WAIT="2" # wait 2 seconds before checking the remote server
2 Likes

I guess I don't know what should be in the account.key.

2 Likes

The account.key file should contain the private key for your ACME account that is automatically generated by your ACME client. CertSage (the ACME client I author) actually generates separate account keys for the staging and production environments.

3 Likes

Hi @timkimber,
I have tried a bunch of things since your original reply. None have worked yet. I hope that you might have a suggestion about how I might figure out why I'm not getting the crt files written after switching from the staging server.
Thanks

3 Likes

@stephening

Do you have any error logs to post? It's quite possible that validation is failing for some reason and thus no certificate is produced. It could be that you don't have a production ACME account registered with Let's Encrypt.

3 Likes

unfortunately there is absolutely nothing written to the console when i run getssl

2 Likes

You could try using CertSage (the ACME client I author) to determine if there's actually a problem interacting properly with Let's Encrypt from your server. CertSage is a single PHP file that will dump all responses from the Let's Encrypt server into a responses.txt file.

3 Likes

Thank you so much for your help. I'm so embarrassed, but I was forgetting to add the domain name to the command line when I ran the getssl script. When I added the -U command to tell it not to check for getssl update, then it printed the help/command line usage. Using cpanel, I installed the ancestryweb.org.crt for the certificate, ancestryweb.org.key for the private key, and I just used the chain.crt for the ca bundle. Now my next step will be to set up a cron job and automatically update the certificate. If you leave this open, I can clearly document, step by step, exactly what I did so someone could follow it without going through all these failed steps of mine.
Thanks again for your patience and persistence with me.
Steve

3 Likes

No need to be embarrassed. Trial and error is inherent in this process (as in most every process). :blush:

Thank you so much for reporting back. We look forward to your explanation.

3 Likes

Yay, it works! The following is a detailed description of what I did to obtain and install a certificate on my site5 hosted website. I do not have su privilege, and the certificate installation is manual for now. I would like to automate it next.

My website is hosted by site5 and at least at my level of hosting, do not have letsencrypt integration.
I do not have su console access either, so it was my understanding that i couldn't directly use Certbot (https://certbot.eff.org/). (it is possible that I misunderstood the su requirement)
I can ssh into the host for my domain by using putty, with the IP address obtained from the web host manager (WHM) and the FTP username and password.
So, I chose the first option from the list of ACME client implementations (ACME Client Implementations - Let's Encrypt).

Open the following URL on your internet browser: https://github.com/srvrco/getssl
Then scroll down to view the README.md contents.

Once logged into a non-su Linux, console, create a work directory and cd to it. I used ~/getssl

Next you can past the following command into the console and execute it (in the README.md)

curl --silent https://raw.githubusercontent.com/srvrco/getssl/master/getssl > getssl ; chmod 700 getssl

Next I typed the command (where <domain> is the domain name I wanted to obtain a certificate for):

./getssl -c <domain>

This will create ~/.getssl and a subfolder with the domain name.

cd to ~/.getssl

then cd to the subfolder

Then open the getssl.cfg file for editing. Scroll down to about line 80 and you will see a commented out line that begins like this: #ACL=('
It doesn't really matter where in the file it is but it's nice to set the ACL variable right above this commented out example. I added above that line the following:

ACL=('/home/.../public_html/.well-known/acme-challenge')

You should fill in the ... with your actual path to where your html files are stored.

Next go to your console and create the .well-known/acme-challenge folders in your html folder. You can actually call it something different if you want as long as the cfg file and the folder created match. The point of this is to prove that you have permission to create files and folders in your domain's file server.

Then going back to your console, go back to the ~/getssl folder and type the following command:

./getssl <domain>

Verify by seeing if crt files are created in ~/.getssl/<domain>

Once you verify that the files are created, delete the *.crt files in the ~/.getssl/<domain> folder, or when you run with the production acme server next, it will fail because your certificates in that folder are not expired yet.

When this seems to be working correctly, the last step is to open the cfg file: ~/.getssl/getssl.cfg

Go down to what is probably the first variable that is uncommented, which begins with: CA="https://acme-staging-v02...

Comment it out and uncomment the line below that start with: #CA="https://acme-v02...

Save and then go back to the folder with the getssl script (~/getssl if you followed the steps above)
Execute the script again:

./getssl <domain>

Assuming this worked, the final step is installing the certificates. I'm sure there are many ways to do this including asking support to install it for you, but I installed my own using cpanel as follows:

  • In my case on site5, i logged into site5.com with my account name/password.
  • Next I clicked on my multisite product/service, which is the hosting service I currently have.
  • Then over on the left side, under Actions, I clicked 'Login to WHM'
  • Under the home page of WHM (Web host manager), I clicked on the 'Account information' tool.
  • On the next page, I clicked the 'List accounts' tool.
  • On this page was a table with all the different domains I had howted on this mutisite account.
  • I then clicked the orange 'CP' just to the right of the domain name of interest.
  • On the next page, i scrolled down to the security section, and clicked on the 'SSL/TLS Status' tool.
  • From there I clicked on the 'View Certificate' hyperlink under certificate status for the domain.
  • In the domain dropdown list, I selected the only option which was the domain and subdomains of interest.
  • Then I pasted the contents of ~/.getssl//.crt into the Certificate (CRT) field.
  • Next I pasted the contents of ~/.getssl//.key into the Private Key (KEY) field.
  • Finally I pasted the contents of ~/.getssl//chain.crt into the Certificate Authority Bundle (CABUNDLE) field.
  • Then, I clicked the 'Install Certificate' button at the bottom.

If successful, you should be able to navigate to your website using https and it should show as secure.
You may need to do some other steps if you want people to be able to do https://www.<domain>

4 Likes

Your config is now trying to use the same account key for production that was used for staging.
I think they are unknown to each other; And should be regenerated.
OR maybe the code could be altered to follow:

[and simply remark out the one you aren't using]

3 Likes

I see what you're saying but I finally got it working without making the change shown.
Thanks,
Steve

3 Likes

It would be great if you could share the solution here.
[for anyone with a similar problem that may come searching for one]

3 Likes

I marked my solution above

3 Likes

A post was split to a new topic: Domain resolved to an IP address that does not exist on this server

@stephening sorry for not being able to help resolve you issue and for not getting back to you (I didn't get any updates that more replies had been posted to the forum and forgot to check).

I've opened a bug report for getssl to fix the 'no output if no domain is specified and no domain is in the config file' problem that you encountered, and I'll add you're really useful instructions on how to get a certificate to the documentation (if that's okay with you)

3 Likes