-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: x/crypto/acme/autocert cluster compatibility #42361
Comments
I'm not sure if DbCache is useful enough on its own, or if people will end up writing their own implementation using the Cache interface regardless, as I assume the nuances of each application's database are too specific to generalize in this package. To get around thundering-herd scenarios of cache expiration, I've implemented probabilistic early expiration in a GCS cache in the past with the current API, which is helpful in scenarios with multiple frontends sharing a certificate. To me, it feels like this proposal is doing too much, and that solving grouped CSR subdomain requests should be separate from any discussion over whether a new DbCache interface is added. |
Yes, you are right, I thought of that. I mention it as my own implementation according to my current configuration. I know that it cannot be generalized, it is not something generic, each one has its own system with or without a database. Using DNS verification (txt record) is not a solution for everyone. Not all providers offer APIs to manipulate dns records.
This is not a problem for me. I can synchronize the certificates on all nodes (pub/sub) or just use a 24h timer task to check if the certificate is updated (or being updated. The first node will update it, for example using priority values).
The DbCache is the less important for me. It is easy to implement one in any storage model. |
Talked with @bradfitz a bit about this. Can anyone think of problems with just reusing the existing cache for holding challenges? |
Today I'm looking at the cache implementation and design. It is poorly designed.
For this reason, any modification of the cache interface in Instead, I'm going to organize the code a bit by separating the cache to be generic and then implementing the missing functions to make it compatible with other future cache implementations. This is frustrating because Over time you end up wasting more time solving problems than developing libraries from scratch. |
@mvasi90 Thanks, but please do not put patches in GitHub issues. Please put them into Gerrit or GitHub pull requests instead, as described at https://golang.org/doc/contribute.html. That will check that the code has the necessary copyright agreement. Thanks. |
@ianlancetaylor, sorry for the disturbances. This has been a guide, the less personal data the third-party algorithms record, the better. The less they know about me, the better. Here my collaboration ends. |
If you are unable to sign a copyright license agreement, then unfortunately we are unable accept your contribution. Closing this issue. |
I'm planning to adapt x/crypto/acme/autocert to work in a cluster with multiple nodes.
Known issues of current autocert
Create a new certificate for each subdomain
This forces you to use an external client to request certificates for other subdomains (like: mail. smtp. imap. etc.)
The SAN field of x509.v3 is needed, in order to avoid external clients and avoid rate limit. (Wildcards aren't a desirable option).
Cache stored in file
This doesn't work in a cluster with multiple nodes. Each node has its own storage.
Decentralized business logic
In a cluster, a node requests the renew of a certificate and the CA server requests the domain verification to another node (internal dynamic DNS, floating IPs, etc.). This doesn't work either.
My approach:
I have the following code for testing
What happens now?
Every time a client connects, (in order to get the corresponding certificate)
ClientHelloInfo
is sent toThe next step is to check if the client supprts the ALPN protocol (if true, it uses the stored certificate. But it is secure? Any client can set ALPN as supported protocol and obtain information, while the authorization flow is active):
If the client does not support ALPN, then it is a regular domain. (What is a regular domain? it Is expected to be any client other than the CA Server?)
My proposal (and my current implementation) is:
Store cache information in the database (centralized for all nodes). This is easy.
Any additional data is needed between nodes?
The main improvement will be the use of the SAN field to add additional subdomains:
The text was updated successfully, but these errors were encountered: