Using Let's Encrypt Staging Certificates on Internal Testing/Staging/Development Environments


#1

Hello

I have just installed Let’s Encrypt on Apache2 server : https://www.peoplejob.com/

But both Firefox and Chrome browser doesn’t trust certificate issuer.
Firefox : sec_error_unknown_issuer
Chrome : NET::ERR_CERT_AUTHORITY_INVALID

SSl Labs told me that Issuer is NOT TRUSTED

Any advice please ?

Thanks


#2

You’re not using the correct production URL.


#3

Or perhaps you’re specifying in Apache the cert.pem instead of fullchain.pem as your certificate.


#4

Hello @Cleno,

As @NurdTurd said, you are creating your certificate using Let’s Encrypt staging (test server) so the cert created for your domain has been issued by happy hacker fake CA. This Let’s Encrypt staging server should be used just to test that your client is working fine and can generate the challenges, certificates… and so on but if you want to create a valid cert you should use the right server in letsencrypt-auto command.

For staging is:
--server https://acme-staging.api.letsencrypt.org/directory

For production is:
--server https://acme-v01.api.letsencrypt.org/directory

In last version of Let’s Encrypt client (0.1.1) if you don’t specify a server it defaults to production and if you want to use staging you can specify the server for staging or just use one of these switches (--test-cert or --staging).

This is the help info for these switches:

--test-cert, --staging
                        Use the staging server to obtain test (invalid) certs;
                        equivalent to --server https://acme-
                        staging.api.letsencrypt.org/directory (default: False)

Cheers,
sahsanu


#5

Yeh perhaps I should have checked your domain. Oops…


#6

Great answer @sahsanu !

Thanks a lot, I’m going to try this using production server. And I’ll tell you the result.

Regards


#7

@sahsanu, obviously it’s by design that the certs issued by staging are not useful, but why? or, in the reverse, why not issue real certs from staging? it causes for everyone to struggle upon seeing that error


#8

Hi @ekkis,

Well, indeed the certs issued by staging server are “real”, the same as the certs issued by production server, the difference is the CA, on staging the CA “Fake LE Intermediate X1” is not trusted by any application, Operating System, Web Browser, etc. but the certs are valid as in production it is just that no ones trust this fake CA.

Production has several rate-limits to avoid abuse. these rate-limits are higher on staging so if you want to test that your machine, your procedure, blabla works fine it is better to test it previously on staging and when you know that your procedure, etc. works fine issue it against production.

The certificates issued by production are also sent to Certificate Transparency Log which comsumes time and resources (keep in mind that we are talking about millions of certificates) so there is no need to consume these resources just because you decided to test Let’s Encrypt certs and created 14 certificates during your tests just to check if it works for you. That is the reason for staging, testting purposes. Also, the new features, bug fixes, etc. are tested also on staging server before to upload them to production.

Really, I see no concern about staging and production, staging should never issue certs using a trusted CA, that is the production’s job.

Cheers,
sahsanu


#9

ah. that makes perfect sense. so what developers need to do in order to avoid these messages is simply trust the staging CA. I would therefore make the suggestion that this procedure be documented to avoid developer confusion (like mine) when getting those error messages


#10

Hi @ekkis

to avoid these messages is simply trust the staging CA

This has already been documented :smiley:

https://letsencrypt.org/docs/staging-environment/

Andrei