Status Update
Comments
se...@google.com <se...@google.com> #2
As I can see, you want to obtain more efficient and quick way to work with SSL certificates. An SSL certificate is not just a public cryptographic key signed by a Certificate Authority. An end entity certificate is hard coded to a specific domain or domains (if it is multi-domain) and organization. These pieces of information assure your visitors that your website isn't just a front set up by a hacker.
Unfortunately, there's no other way than creating a new certificate in case of any changes.
da...@noldor.co.za <da...@noldor.co.za> #3
I understand, this. My request is that you make this process easy to do via the cli or interface
As an example, I would simply "edit" a current certificate on the UI add/remove domains to that cert and save, but in the background you are actually creating a new cert and associating it as well as dissociating the old one
se...@google.com <se...@google.com> #4
da...@noldor.co.za <da...@noldor.co.za> #5
se...@google.com <se...@google.com>
[Deleted User] <[Deleted User]> #6
st...@gmail.com <st...@gmail.com> #7
It would be nice to be able to edit ssl certificates.
mi...@gmail.com <mi...@gmail.com> #8
[Deleted User] <[Deleted User]> #9
[Deleted User] <[Deleted User]> #10
Instead of verifying ownership of a domain via subdomain to IP address mapping, why can't that just be proven via TXT records? That way a certificate could be verified before its required to be active and in use.
[Deleted User] <[Deleted User]> #11
ho...@gmail.com <ho...@gmail.com> #12
ca...@gmail.com <ca...@gmail.com> #13
ma...@chainguard.dev <ma...@chainguard.dev> #14
However, since adding domains requires replacement (due to the lack of an update), and you cannot replace an in-use certificate, users are left to do a complex / errorprone orchestration themselves.
co...@sercanto.com <co...@sercanto.com> #15
This blog post by a Google engineer offers a potential solution to the downtime problem:
Quoting the relevant parts in case the article gets de-published:
[...] we cannot simply update the load balancer to use the new certificate. That would cause downtime as it can take up to 60 minutes to provision the certificate and up to 30 more minutes for the certificate to be available on the load balancer. That means changing the certificate could result in up to 90 minutes of downtime. Instead, we need to update the target HTTPS proxy to use both certificates simultaneously. This will give the DV validation time to succeed without removing the already-provisioned certificates.
gcloud compute target-https-proxies update "example-com" \ --ssl-certificates "projects/MY_PROJECT/global/sslCertificates/example-com-certs,projects/MY_PROJECT/global/sslCertificates/example-com-certs-2"
During this time, the initial certificate will remain green while the new certificate provisions. After the new certificate is finished provisioning, you can safely update the HTTPS proxy to remove the old one:
gcloud compute target-https-proxies update "example-com" \ --ssl-certificates "projects/MY_PROJECT/global/sslCertificates/example-com-certs-2"
HTH
Description
Currently the only way to change the list of associated domains is to create a new certificate, duplicating the domain list whilst adding/removing as required. This is an error prone and tedious process, which also requires that 1 of the 15 certificates be available at all times, a waste of this resource
We should be able to edit a certificate on the fly and add/remove the relevant domains and have the certificate update once complete