Easy HTTPs在ACMEv2发布后第一时间跟进开发，并在Easy HTTPs中自动开通了泛域名证书（通配符SSL安全证书的申请）申请服务，要使用泛域名SSL证书申请，只要在子域名中输入*即可创建并生成。
但请注意，目前通配符证书仅用于测试，不被浏览器信作。我们将在Let's Encrypt开通正式环境后第一时间向广大用户提供生成服务（系统将自动切换）。
Let’s Encrypt and the ACME standard have evolved side-by-side since our launch. As the draft has moved through the IETF standardization process we accumulated a number of divergences51 where the specification changed in non-backwards-compatible ways. Now that the draft standard is in last-call and the pace of major changes has slowed, we’re able to release a “v2” API that is much closer to what will become the final ACME RFC. We may plan to sunset the v1 API at some point in the future, but have not set a date. We will give plenty of advance warning to clients and integrators for any such plan.
Existing ACME accounts from the v1 API will work with the v2 API. Existing authorizations from the v1 API will not be usable with the v2 API, meaning that you will have to reauthorize all domains prior to issuance with the v2 API (note: this is not currently implemented in the staging API, so you may see some reuse there).
The existing staging environment rate limits74 still apply for the V2 API. There’s one new rate limit, Pending Orders Per Account. One ACME account can have no more than 300 pending orders outstanding at a time.
This is a non-backward-compatible version of the API, so ACME v1 clients (almost all clients available today) will not work with the ACME v2 endpoint. Existing clients will need code changes and new releases in order to support ACME v2.
Certbot is not yet ACME v2 compatible. We expect Certbot to support ACME v2 by February 27. To date, only
ACME4J160 has implemented ACME v2. Please start a new thread in the “client dev” category on the forum 81 to let us know if your ACME client has added v2 support! We will soon start marking ACME v2 compatible clients in our list of available ACME clients.194
If you use an ACME v1 client with the ACME v2 API you will likely receive errors about an incompatible /directory response, perhaps mentioning missing endpoints (new-reg, new-authz, etc). To reiterate, ACME v1 clients will not work with ACME v2 without code changes.
The V2 API supports issuing wildcard certificates. To request a wildcard certificate simply send a wildcard DNS identifier in the newOrder request. Wildcard identifiers may only be authorized by DNS-01 challenge, so order authorizations corresponding to wildcard identifiers will only include a pending DNS-01 challenge. DNS names in certificates may only have a single wildcard character, and it must be the entire leftmost DNS label, for instance “*.example.com”. A single certificate can have wildcard DNS identifiers for multiple base domains.
ACME v2 has a number of differences from the v1 API based on earlier drafts. Here are a few of the high level changes we want to draw client developer attention to:
Previously clients requested individual authorizations per-identifier using the new-authz endpoint, satisfied challenges associated with those authorizations, and then submitted a CSR to the new-cert. With the V2 API clients will create a new-order for a number of identifiers, receive authorizations in the order response, satisfy challenges associated with those authorizations, and then finalize the order by sending a CSR to its finalization URI.
In ACME all POST requests are authenticated by a JWS signature. In ACME v1, the key to verify that signature with was included in the JWS headers. In ACME v2 only the newAccount and revokeCert endpoints follow this pattern. All other endpoints expect a JWS “kid” (key ID) header, with the contents of the header set to the account URL authorizing the request.
ACME v2 also replaces the resource field from JWS request bodies. Previously clients would include the resource name they intended to POST to in the JWS body’s “resource” field to ensure the signed body couldn’t be used for a different resource/endpoint. In ACME v2 clients now include the URL they are POSTing as a JWS protected header.
ACME v2 applies a consistent "camelCase" for all field names. This means ACME v1 directory entries like revoke-cert and new-account are now revokeCert and newAccount.
In ACME v2, clients are expected to fetch the Terms of Service before creating an account, and simply set the termsOfServiceAgreed field to true in their newAccount field. The Terms of Service (aka Subscriber Agreement) can be found in the “termsOfService” field in the “meta” section of the directory object. Note that Boulder currently has a non-standard /terms URL. In the v1 API, we will keep this for backwards compatibility but in v2 we will remove it shortly.
There’s also a new challenge type, TLS-SNI-02. This is very similar to TLS-SNI-01, but computes different values for the challenge certificate to reduce implementation errors for clients. Our plan is to offer only TLS-SNI-02 in ACME v2, but as of today, our ACME v2 endpoint offers TLS-SNI-01 and not TLS-SNI-02.
There are a number of other changes that have been made and we encourage developers to read the most ACME draft, ACME Draft-09111 for full details.