Re: acme-client(1): backup certs
On Sun, Jan 03, 2021 at 11:16:00AM +, Stuart Henderson wrote: > What are you thinking would be stolen? The certificates themselves > are public knowledge anyway - they are sent in full whenever someone > connects to your TLS-based service and are available from Certificate > Transparency log servers (https://crt.sh etc) - but they are useless > without the private key. That's exactly what concerns me. I rent servers. Physical access always breaks security if someone really wants to. If it wasn't so insane in the Big Tech companies right now, I would only place my paranoia with some bad guy in the server room. But I have two sites that just have copies of the US and Texas Declarations of Independence, The US Constitution, Hammarabi's legal code and just stuff like that. Nothing with any opinions. I also walk past small shops permanently out of business every day, so I find it tough not to be a little paranoid. I do keep all my sites with DNSSEC. Except this one. As I tried to move it, I found all kinds of restrictions on sites with endings like .us IMO, really stupid, but oh well. Going to try to move it again next couple of days. I really don't maintain bennettconstruction.us, it's just sentimental value for me and what was. Chris > > > Especially since DNS servers can take up to 48 hours to propagate changes > > So getting rid of www.domain.xxx might not show up quickly enough. > > And if I change IP addresses and they don't get propagated soon enough, > > wouldn't someone be able to briefly spoof my site? > > letsencrypt (and I think probably all CAs) do uncached lookups from the > authoritative servers for the domain, following the chain from the root > servers, the usual problem with DNS servers returning outdated records > is with bad recursive servers. > > If you have problems getting the authoritative servers giving out current > information then that needs fixing, and isn't really a problem specific > to CA validation. >
Re: acme-client(1): backup certs
ok
Florian Obser(flor...@openbsd.org) on 2021.01.02 17:23:11 +0100:
>
> Create .1 backup files when acme-client is going to overwrite a
> certificate file.
>
> This files are not terribly big and it's convenient to keep one
> previous file around for example if one adds or removes domains to the
> certificate and then wants to revoke the previous one.
>
> (Note that it's kinda difficult to revoke the old certificate with
> acme-client currently. The whole revoke machinery needs to be
> overhauled. I have ideas...)
>
> Comments, OKs?
>
> diff --git acme-client.conf.5 acme-client.conf.5
> index 3c5fd1c2362..3fdd40a5eb0 100644
> --- acme-client.conf.5
> +++ acme-client.conf.5
> @@ -149,6 +149,11 @@ The filename of the certificate that will be issued.
> This is optional if
> .Ar domain full chain certificate
> is specified.
> +A backup with name
> +.Ar file.1
> +is created if
> +.Ar file
> +exists.
> .It Ic domain chain certificate Ar file
> The filename in which to store the certificate chain
> that will be returned by the certificate authority.
> @@ -156,6 +161,11 @@ It needs to be in the same directory as the
> .Ar domain certificate
> (or in a subdirectory) and can be specified as a relative or absolute path.
> This setting is optional.
> +A backup with name
> +.Ar file.1
> +is created if
> +.Ar file
> +exists.
> .It Ic domain full chain certificate Ar file
> The filename in which to store the full certificate chain
> that will be returned by the certificate authority.
> @@ -170,6 +180,11 @@ in one file, and is required by most browsers.
> This is optional if
> .Ar domain certificate
> is specified.
> +A backup with name
> +.Ar file.1
> +is created if
> +.Ar file
> +exists.
> .It Ic sign with Ar authority
> The certificate authority (as declared above in the
> .Sx AUTHORITIES
> diff --git fileproc.c fileproc.c
> index b7cdff5525d..cc3aa293712 100644
> --- fileproc.c
> +++ fileproc.c
> @@ -34,6 +34,19 @@ serialise(const char *real, const char *v, size_t vsz,
> const char *v2, size_t v2
> int fd;
> char *tmp;
>
> + /* create backup hardlink */
> + if (asprintf(&tmp, "%s.1", real) == -1) {
> + warn("asprintf");
> + return 0;
> + }
> + (void) unlink(tmp);
> + if (link(real, tmp) == -1 && errno != ENOENT) {
> + warn("link");
> + free(tmp);
> + return 0;
> + }
> + free(tmp);
> +
> /*
>* Write into backup location, overwriting.
>* Then atomically do the rename.
>
> --
> I'm not entirely sure you are real.
>
Re: acme-client(1): backup certs
On 2021/01/02 17:10, Chris Bennett wrote: > On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote: > > > > Create .1 backup files when acme-client is going to overwrite a > > certificate file. > > > > This files are not terribly big and it's convenient to keep one > > previous file around for example if one adds or removes domains to the > > certificate and then wants to revoke the previous one. > > > > (Note that it's kinda difficult to revoke the old certificate with > > acme-client currently. The whole revoke machinery needs to be > > overhauled. I have ideas...) > > > > Comments, OKs? > > > > Wait, I can have multiple, active certificates? One's that are in fact > different, such as domain.xxx and then add www.domain.xxx in another > certificate? > > If that's the case, then couldn't someone steal the old or new one and > use that to cause problems? What are you thinking would be stolen? The certificates themselves are public knowledge anyway - they are sent in full whenever someone connects to your TLS-based service and are available from Certificate Transparency log servers (https://crt.sh etc) - but they are useless without the private key. > Especially since DNS servers can take up to 48 hours to propagate changes > So getting rid of www.domain.xxx might not show up quickly enough. > And if I change IP addresses and they don't get propagated soon enough, > wouldn't someone be able to briefly spoof my site? letsencrypt (and I think probably all CAs) do uncached lookups from the authoritative servers for the domain, following the chain from the root servers, the usual problem with DNS servers returning outdated records is with bad recursive servers. If you have problems getting the authoritative servers giving out current information then that needs fixing, and isn't really a problem specific to CA validation.
Re: acme-client(1): backup certs
On Sat, Jan 02, 2021 at 05:10:01PM -0600, Chris Bennett wrote: > On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote: > > > > Create .1 backup files when acme-client is going to overwrite a > > certificate file. > > > > This files are not terribly big and it's convenient to keep one > > previous file around for example if one adds or removes domains to the > > certificate and then wants to revoke the previous one. > > > > (Note that it's kinda difficult to revoke the old certificate with > > acme-client currently. The whole revoke machinery needs to be > > overhauled. I have ideas...) > > > > Comments, OKs? > > > > Wait, I can have multiple, active certificates? One's that are in fact > different, such as domain.xxx and then add www.domain.xxx in another > certificate? > > If that's the case, then couldn't someone steal the old or new one and > use that to cause problems? > Especially since DNS servers can take up to 48 hours to propagate changes > So getting rid of www.domain.xxx might not show up quickly enough. > And if I change IP addresses and they don't get propagated soon enough, > wouldn't someone be able to briefly spoof my site? > DNS servers in some places I have been to, do in fact have failures. > > If I understand this correctly (perhaps not), this seems like a major > security problem with DNS. Especially if my spoofed site sends people to > another site that they then bookmark. Hi, Yes you can have multiple certs, I have a few. The spoofing couldn't happen if you used DNSSEC. However if you used DNSSEC that means you have to keep your keys on the DNS Server, in order to sign the domain with acme-client info, which you have to be comfortable with. If they get stolen, then you have to change the keys and your domains will be temporarely insecure and subject to spoofing again. Regarding to the "propagation time" you should keep your TTL's low in that case, I think. That is not always wanted. Luckily you have the choice to use the DNS vs. the HTTP method. I think it's good you went into a deep thought about this, as it makes everyone think how to refine the process of getting let's encrypt certs. > Chris Bennett Best Regards, -peter
Re: acme-client(1): backup certs
On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote: > > Create .1 backup files when acme-client is going to overwrite a > certificate file. > > This files are not terribly big and it's convenient to keep one > previous file around for example if one adds or removes domains to the > certificate and then wants to revoke the previous one. > > (Note that it's kinda difficult to revoke the old certificate with > acme-client currently. The whole revoke machinery needs to be > overhauled. I have ideas...) > > Comments, OKs? > Wait, I can have multiple, active certificates? One's that are in fact different, such as domain.xxx and then add www.domain.xxx in another certificate? If that's the case, then couldn't someone steal the old or new one and use that to cause problems? Especially since DNS servers can take up to 48 hours to propagate changes So getting rid of www.domain.xxx might not show up quickly enough. And if I change IP addresses and they don't get propagated soon enough, wouldn't someone be able to briefly spoof my site? DNS servers in some places I have been to, do in fact have failures. If I understand this correctly (perhaps not), this seems like a major security problem with DNS. Especially if my spoofed site sends people to another site that they then bookmark. Chris Bennett
acme-client(1): backup certs
Create .1 backup files when acme-client is going to overwrite a
certificate file.
This files are not terribly big and it's convenient to keep one
previous file around for example if one adds or removes domains to the
certificate and then wants to revoke the previous one.
(Note that it's kinda difficult to revoke the old certificate with
acme-client currently. The whole revoke machinery needs to be
overhauled. I have ideas...)
Comments, OKs?
diff --git acme-client.conf.5 acme-client.conf.5
index 3c5fd1c2362..3fdd40a5eb0 100644
--- acme-client.conf.5
+++ acme-client.conf.5
@@ -149,6 +149,11 @@ The filename of the certificate that will be issued.
This is optional if
.Ar domain full chain certificate
is specified.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic domain chain certificate Ar file
The filename in which to store the certificate chain
that will be returned by the certificate authority.
@@ -156,6 +161,11 @@ It needs to be in the same directory as the
.Ar domain certificate
(or in a subdirectory) and can be specified as a relative or absolute path.
This setting is optional.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic domain full chain certificate Ar file
The filename in which to store the full certificate chain
that will be returned by the certificate authority.
@@ -170,6 +180,11 @@ in one file, and is required by most browsers.
This is optional if
.Ar domain certificate
is specified.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic sign with Ar authority
The certificate authority (as declared above in the
.Sx AUTHORITIES
diff --git fileproc.c fileproc.c
index b7cdff5525d..cc3aa293712 100644
--- fileproc.c
+++ fileproc.c
@@ -34,6 +34,19 @@ serialise(const char *real, const char *v, size_t vsz, const
char *v2, size_t v2
int fd;
char *tmp;
+ /* create backup hardlink */
+ if (asprintf(&tmp, "%s.1", real) == -1) {
+ warn("asprintf");
+ return 0;
+ }
+ (void) unlink(tmp);
+ if (link(real, tmp) == -1 && errno != ENOENT) {
+ warn("link");
+ free(tmp);
+ return 0;
+ }
+ free(tmp);
+
/*
* Write into backup location, overwriting.
* Then atomically do the rename.
--
I'm not entirely sure you are real.
