Re: acme-client.conf example: more explicit clue to test with staging server
We put *a lot* of work in so that a simple search & replace of example.com in
acme-client.conf and httpd.conf examples would give a working configuration.
So I would object to the previous diff.
I'm not convinced this one will help(*) but no objection from me either.
*) People don't read, we already know that.
On 9 May 2023 21:45:30 CEST, Theo Buehler wrote:
>On Tue, May 09, 2023 at 08:48:06PM +0200, Theo Buehler wrote:
>> espie mentioned that the clue to use the staging server could be more
>> explicit.
>> Maybe this is enough and not too intrusive?
>
>Some expressed concern that it should be done the other way around,
>i.e., leave the default at letsencrypt. Perhaps it's indeed better
>this way to avoid creating servers with bad certs.
>
>Index: examples/acme-client.conf
>===
>RCS file: /cvs/src/etc/examples/acme-client.conf,v
>retrieving revision 1.4
>diff -u -p -r1.4 acme-client.conf
>--- examples/acme-client.conf 17 Sep 2020 09:13:06 - 1.4
>+++ examples/acme-client.conf 9 May 2023 19:39:12 -
>@@ -27,5 +27,7 @@ domain example.com {
> alternative names { secure.example.com }
> domain key "/etc/ssl/private/example.com.key"
> domain full chain certificate "/etc/ssl/example.com.fullchain.pem"
>+ # Test with the staging server to avoid aggressive rate-limiting.
>+ #sign with letsencrypt-staging
> sign with letsencrypt
> }
>
--
Sent from a mobile device. Please excuse poor formatting.
Re: acme-client.conf example: more explicit clue to test with staging server
On Tue, 09 May 2023 21:45:30 +0200, Theo Buehler wrote: > Some expressed concern that it should be done the other way around, > i.e., leave the default at letsencrypt. Perhaps it's indeed better > this way to avoid creating servers with bad certs. OK millert@ for this version - todd
Re: acme-client.conf example: more explicit clue to test with staging server
On Tue, May 09, 2023 at 08:48:06PM +0200, Theo Buehler wrote:
> espie mentioned that the clue to use the staging server could be more
> explicit.
> Maybe this is enough and not too intrusive?
Some expressed concern that it should be done the other way around,
i.e., leave the default at letsencrypt. Perhaps it's indeed better
this way to avoid creating servers with bad certs.
Index: examples/acme-client.conf
===
RCS file: /cvs/src/etc/examples/acme-client.conf,v
retrieving revision 1.4
diff -u -p -r1.4 acme-client.conf
--- examples/acme-client.conf 17 Sep 2020 09:13:06 - 1.4
+++ examples/acme-client.conf 9 May 2023 19:39:12 -
@@ -27,5 +27,7 @@ domain example.com {
alternative names { secure.example.com }
domain key "/etc/ssl/private/example.com.key"
domain full chain certificate "/etc/ssl/example.com.fullchain.pem"
+ # Test with the staging server to avoid aggressive rate-limiting.
+ #sign with letsencrypt-staging
sign with letsencrypt
}
