SSL newb. Please help

Help
1

OS: Debian 8.

Domain: https://vetco.net

Self-hosted, dedicated hardware.

As root-user, I followed the “instructions” here:

Specifically:

Step-1. Ran this command:

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

Step-2. Then this command:

./getssl -c vetco.net

Step-3. Edited this file:

/root/.getssl/getssl.cfg

Changed the ACCOUNT_EMAIL directive to my e-mail address. No other changes.

Step-4. Edited this file:

/root/.getssl/vetco.net/getssl.cfg

Commented the SANS= directive, because I have exactly 1 domain.

Specified ACL directive to:

ACL=('/var/www/vetco/current/public/.well-known/acme-challenge')

Un-commented 2 directives:

DOMAIN_CERT_LOCATION="/etc/ssl/vetco.net.crt"
DOMAIN_KEY_LOCATION="/etc/ssl/vetco.net.key"

Saved file.

Step-5. Ran this command:

getssl vetco.net

Output:

./getssl vetco.net
creating account key /root/.getssl/account.key
creating key - /root/.getssl/account.key
Generating RSA private key, 4096 bit long modulus
.................................++
...............................................................................................................................++
e is 65537 (0x10001)
creating key - /root/.getssl/vetco.net/vetco.net.key
Generating RSA private key, 4096 bit long modulus
...................................................................................................++
.................................................................................................................................................................................................................................................................................++
e is 65537 (0x10001)
creating domain csr - /root/.getssl/vetco.net/vetco.net.csr
Registering account
Registered
Verify each domain
Verifying vetco.net
copying challenge token to /var/www/vetco/current/public/.well-known/acme-challenge/...
Pending
Verified vetco.net
Verification completed, obtaining certificate.
Certificate saved in /root/.getssl/vetco.net/vetco.net.crt
The intermediate CA cert is in /root/.getssl/vetco.net/chain.crt
copying domain certificate to /etc/ssl/vetco.net.crt
copying private key to /etc/ssl/vetco.net.key
getssl: vetco.net - certificate obtained but certificate on server is different from the new certificate

Step-6. Edit Nginx config:

server{
        listen 443 ssl;
	ssl on;
        server_name vetco.net;

	ssl_certificate /etc/ssl/vetco.net.crt;
	ssl_certificate_key /etc/ssl/vetco.net.key;
        ...
}

Step-7. Reload Nginx config.

Step-8. Visit website:

“Safari can’t verify the identity of the website Vetco.net”

“The certificate for this site is invalid… this certificate was signed by an untrusted issuer…”, etc.

What do I need to do?

If you go to the website right now, yes, the SSL-cert is fine, because I have reverted the Nginx-config to previous values. However, certs expire in 7 days, so I need to renew.

2

Hello @vetcovetco,

Did you read this part of the documentation?

This will (by default) use the staging server, so should give you a certificate that isn't trusted ( Fake Let's Encrypt). Change the server in your config file to get a fully valid certificate.

Seems your cert has been issued by the staging server, you should modify your conf to point to production server, something like this:

# Uncomment and modify any variables you need
# The staging server is best for testing (hence set as default)
#CA="https://acme-staging.api.letsencrypt.org"
# This server issues full certificates, however has rate limits
CA="https://acme-v01.api.letsencrypt.org"

Cheers,
sahsanu

2 Likes
3

Did you read this part of the documentation?

Yes. And then I ignored it, because I'm a pro at that. :blush:

I made the change and repeated the process and it works.

Thank you @sahsanu!

2 Likes
4

Hi @vetcovetco,

I’m glad you solved this issue.

Just one more thing, right now your server just provide your cert but not the Let’s Encrypt cert which could cause issues. In your nginx config you should point the directive ssl_certificate to the file containing the fullchain.

I don’t know whether getssl generates it automatically or should be specified in the getssl.cfg uncommenting the variable DOMAIN_CHAIN_LOCATION and giving the right path where you want to save this fullchain file.

Also, you should review your ssl conf, dh params file and ciphers used, some of them are vulnerable to certain attacks, you can view these issues testing your domain here https://www.ssllabs.com/ssltest/

And this site could be useful to get a good ssl config base for your web server https://mozilla.github.io/server-side-tls/ssl-config-generator/

It is a bit late here so I’m disconnecting now but if you have any doubt or problem I will check this post in a few hours.

Good luck,
sahsanu

1 Like
5

Hmm... when going to www.vetco.net, I am presented with a warning about my certificate. I assume this has to do with my SANS directive. Earlier, it contained www.vetco.net, but I commented-out the entire SANS directive.

Now, after making edits to my getssl.cfg, and run ./getssl vetco.net, I am told:

certificate is valid for more than 30 days

Do I have to wait 30 days before I can fix this?

6

Hi again @vetcovetco,

Yes, your certificate only includes vetco.net and no other subdomain.

No, you don't need to wait 30 days to "fix" your cert ;). Indeed that message says that you should wait 60 days to renew your cert. Let's Encrypt certs are valid for 90 days and getssl only will try to renew them if they validity is lower than 30 days.

Once you have configured your getssl.cfg to include your other subdomains, you can override this behaviour editing getssl.cfg and changing the variable RENEW_ALLOW="30" by RENEW_ALLOW="90" and then launch again the command to get the cert for your domains ./getssl vetco.net

or instead of edit the conf file to modify the variable RENEW_ALLOW you can launch the command with -f (--force) parameter to avoid the RENEW_ALLOW directive.

./getssl -f vetco.net

Note: If you modify the variable, remember to get back to 30 once you get your cert or if you use the -f parameter, remember to not use it to renew your cert or you could issue more certs than you want hitting the Let's Encrypt limit.

I hope this helps.

Cheers,
sahsanu.

1 Like
7

Sweet. The -f flag worked.

Per your earlier suggestion, I am using the values from these directives:

  1. DOMAIN_CHAIN_LOCATION => ssl_certificate
  2. DOMAIN_PEM_LOCATION => ssl_certificate_key

Thank you again, @sahsanu.

8

Great :wink:

DOMAIN_CHAIN_LOCATION is ok but instead of DOMAIN_PEM_LOCATION you should use the file defined in variable DOMAIN_KEY_LOCATION.

And again, you should generate your own dh file (it could take a while):

openssl dhparam -out /etc/ssl/nginx-dhparam.pem 2048

Once created you need to modify your nginx https server block and add/modify the directive ssl_dhparam pointing to the new dh file:

ssl_dhparam /etc/ssl/nginx-dhparam.pem;

Cheers,
sahsanu

9

What's the current default behavior of popular web servers with respect to DHE ciphersuites and parameters? Did they switch to using RFC 7919 parameters? Should Certbot be generating custom parameters too?

I'm pretty confident I looked into this last year and found there wasn't a reason to be concerned, but I don't remember the results of my investigation at the moment.

10

I didn't know that RFC so I'm taking a look, anyway, this is something you should not worry about, recent versions should not have any issue with DHE ciphersuites and parameters, at least using Debian that is the system I use. The only reason I recommended vetcovetco to generate his own dh params file is because ssllabs test detects that his web server uses common DH primes and it only uses 1024 bits.

Cheers,
sahsanu

11

Done!

Done!

Now we get an "A-". :slight_smile:

Thank-you again @sahsanu. I found your instructions very clear.

1 Like
12

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