Originally created by @ggiesen on GitHub (Sep 28, 2016).
Would it be possible to implement the ability to delay symlinking to the new cert for x days/invocations/etc to allow time to update TLSA records before the cert is made active.
Perhaps create a new symlink when the cert is created (such as fullchain-new.pem/chain-new.pem/cert-new.pem) which would give a good way for the tlsa script to grab the hash, and then after x invocations or days pull the symlink and re-symlink fullchain.pem to the new cert.
Originally created by @ggiesen on GitHub (Sep 28, 2016).
Would it be possible to implement the ability to delay symlinking to the new cert for x days/invocations/etc to allow time to update TLSA records before the cert is made active.
Perhaps create a new symlink when the cert is created (such as fullchain-new.pem/chain-new.pem/cert-new.pem) which would give a good way for the tlsa script to grab the hash, and then after x invocations or days pull the symlink and re-symlink fullchain.pem to the new cert.
I was also thinking about this, exactly for the same reason. But I think this is already possible with a hook script. In this case, I would not let my web server use the cert directly from $BASEDIR/certs/$DOMAIN/, but from a different location. The hook script then creates an entry in /etc/cron.d that waits for the TLSA record TTL to run out, and then copies the certificate to the new location and restarts the web server.
@rohieb commented on GitHub (Sep 28, 2016):
I was also thinking about this, exactly for the same reason. But I think this is already possible with a hook script. In this case, I would not let my web server use the cert directly from `$BASEDIR/certs/$DOMAIN/`, but from a different location. The hook script then creates an entry in `/etc/cron.d` that waits for the TLSA record TTL to run out, and then copies the certificate to the new location and restarts the web server.
Yeah that'd certainly work, but would require a separate hook script for each service. I was trying to keep the hook script generic (well, specific to the DNS server, but generic in terms of the service it's supporting).
@ggiesen commented on GitHub (Sep 28, 2016):
Yeah that'd certainly work, but would require a separate hook script for each service. I was trying to keep the hook script generic (well, specific to the DNS server, but generic in terms of the service it's supporting).
Mh, I don't think this has a good place in this script so I'm closing this issue.
What will be coming (hopefully kinda soonish) is private key rollover for use with HPKP, would this maybe also solve the problem with TLSA records?
@lukas2511 commented on GitHub (Sep 29, 2016):
Mh, I don't think this has a good place in this script so I'm closing this issue.
What will be coming (hopefully kinda soonish) is private key rollover for use with HPKP, would this maybe also solve the problem with TLSA records?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ggiesen on GitHub (Sep 28, 2016).
Would it be possible to implement the ability to delay symlinking to the new cert for x days/invocations/etc to allow time to update TLSA records before the cert is made active.
Perhaps create a new symlink when the cert is created (such as fullchain-new.pem/chain-new.pem/cert-new.pem) which would give a good way for the tlsa script to grab the hash, and then after x invocations or days pull the symlink and re-symlink fullchain.pem to the new cert.
@rohieb commented on GitHub (Sep 28, 2016):
I was also thinking about this, exactly for the same reason. But I think this is already possible with a hook script. In this case, I would not let my web server use the cert directly from
$BASEDIR/certs/$DOMAIN/, but from a different location. The hook script then creates an entry in/etc/cron.dthat waits for the TLSA record TTL to run out, and then copies the certificate to the new location and restarts the web server.@ggiesen commented on GitHub (Sep 28, 2016):
Yeah that'd certainly work, but would require a separate hook script for each service. I was trying to keep the hook script generic (well, specific to the DNS server, but generic in terms of the service it's supporting).
@lukas2511 commented on GitHub (Sep 29, 2016):
Mh, I don't think this has a good place in this script so I'm closing this issue.
What will be coming (hopefully kinda soonish) is private key rollover for use with HPKP, would this maybe also solve the problem with TLSA records?