* Initial implementation of ZeroSSL API issuer
Still needs CA support for CommonName-less certs
* Accommodate ZeroSSL CSR requirements; fix DNS prop check
* Fix README example
* Fix comment
* Fix advanced cache initialization in README
As per the documentation of GetConfigForCert:
> The returned Config MUST be associated with the same Cache as the caller.
A valid Config cannot be constructed with &certmagic.Config{} as the certCache field is unexported.
The only way to construct a Config with a non-nil Cache is to use either NewDefault or New.
* Make it an error for GetConfigForCert to return Config w/ nil cache
This prevents an invalid Config from slipping through and causing a hard to
debug nil pointer dereference at some later point.
This is necessary to eliminate confusing naming conventions, since now
we have Manager types, having an issuer called ACMEManager was
confusing.
CertificateManager is a redundant name as this package is called
CertMagic, so that a Manager manages certificates should be obvious.
It's also more succinct. Plus, it's consistent with Issuer which is not
named CertificateIssuer.
Breaking changes; thank goodness we're not 1.0 yet 😅 - read on!
This change completely separates ACME-specific code from the rest of the
certificate management process, allowing pluggable sources for certs
that aren't ACME.
Notably, most of Config was spliced into ACMEManager. Similarly, there's
now Default and DefaultACME.
Storage structure had to be reconfigured. Certificates are no longer in
the acme/ subfolder since they can be obtained by ways other than ACME!
Certificates moved to a new certificates/ subfolder. The subfolders in
that folder use the path of the ACME endpoint instead of just the host,
so that also changed. Be aware that unless you move your certs over,
CertMagic will not find them and will attempt to get new ones. That is
usually fine for most users, but for extremely large deployments, you
will want to move them over first.
Old certs path:
acme/acme-staging-v02.api.letsencrypt.org/...
New certs path:
certificates/acme-staging-v02.api.letsencrypt.org-directory/...
That's all for significant storage changes!
But this refactor also vastly improves performance, especially at scale,
and makes CertMagic way more resilient to errors. Retries are done on
the staging endpoint by default, so they won't count against your rate
limit. If your hardware can handle it, I'm now pretty confident that you
can give CertMagic a million domain names and it will gracefully manage
them, as fast as it can within internal and external rate limits, even
in the presence of errors. Errors will of course slow some things down,
but you should be good to go if you're monitoring logs and can fix any
misconfigurations or other external errors!
Several other mostly-minor enhancements fix bugs, especially at scale.
For example, duplicated renewal tasks (that continuously fail) will not
pile up on each other: only one will operate, under exponential backoff.
Closes#50 and fixes#55
I've decided that the purpose of the internal rate limiter is not to
enforce the CA's rate limits, which only the CA can really do properly.
Instead, they are to avoid hammering the CA endpoint with excessive
requests.
Split Manage() into ManageSync() and ManageAsync().
In accordance with developing best practices, ACME operations should be
allowed to happen in the background and not block server startup in
non-interactive environments.
We also no longer return an error during batch cert renewals, because
we always treat it as a background operation. (The ManageSync() method
can perform foreground renewal if that is desired.)
The MaxObtain and other checks such as rate limiting were crippling to
some use cases at scale and incorrect if configs are short-lived; these
changes allow the user to implement their own rate limiting (and simply
limiting the number of certificates to obtain is a bad idea and
shouldn't be done) and to better enforce hostname whitelists for
on-demand config when the high-level functions are used
* Significant refactor
This refactoring expands the capabilities of the library for advanced
use cases, as well as improving the overall architecture, including
possible memory leak fixes if used over a long period with many certs
loaded into memory. This refactor enables using different configs
depending on the certificate.
The public API has changed slightly, however, and arguably it is
slightly less convenient/elegant. I have never quite found the perfect
design for this package, and this certainly isn't it, but I think it's
better than what we had before.
There is still work to be done, but this is a good step forward. I've
decoupled Storage from Cache, and made it easier and more correct for
Configs (and Storage values) to be short-lived. Cache is the only value
that should be long-lived.
Note that CertMagic no longer automatically takes care of storage (i.e.
it used to delete old OCSP staples, but now it doesn't). The functions
to do this are still there and even exported, and now we expect the
application to call the cleanup functions when it wants to.
* Fix little oopsies
* Create Manager abstraction so obtain/renew isn't limited to ACME
* use go-acme/lego
* Use master branch of go-lego/acme since v2.3.0 still has a dependency on xenolf/lego
* Use golangci-lint since gometalinter is depricated
* different way of installing golangci-lint for appveyor
* Removing golangci-lint from Appveyor because of https://github.com/client9/shlib/issues/13
* Replace TryLock and Wait with Lock, and check for idempotency (issue #5)
* Fix logic of lock waiter creation in FileStorage (+ improve client log)
* Return from Wait() if lock file becomes stale
* Remove racy deletion of empty lock folder
* move all (FileStorage) methods to (*FileStorage) so assignments to fields like fileStorageNameLocks aren't lost
* rework lock acquisition
* Create lockDir just before lock file creation to reduce the chance that another process calls Unlock() and removes lockDir while we were waiting, preventing us from creating the lock file.
* Use the same strategy that Wait() uses to avoid depending on internal state.
* fix unlock of unlocked mutex
* Move fileStorageNameLocksMu into FileStorage struct
* implement new lockfile removal strategy and simplify the lock acquisition loop.
* readme: Add link to full examples
* Rework file lock obtaining and waiting logic
* Remove not-useful optimization to simplify file-locking logic
