[plamo:33185] getssl

[山本 伸一]

山本です。

立て続けにすみません。
一つ解決したので、久しぶりに getssl で証明書を作ろうとしたら、
HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 15 Nov 2019 07:48:23 GMT
Content-Type: application/problem+json
Content-Length: 280
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Replay-Nonce: 0001yiudJDEd0zQ1Uvuva5Ja300BUUEAz6ezGvit6EEL2Pk


response {
  "type": "urn:acme:error:unauthorized",
  "detail": "Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.",
  "status": 403
}

code 403

response status =
getssl: Error registering account ...  "Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https

が表示されて、示されるURLを見たら
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
The original protocol used by Let’s Encrypt for certificate issuance and management is called ACMEv1. In March of 2018 we introduced support for ACMEv2, a newer version of the protocol that matches what was finalized today as RFC 8555 285. We have been encouraging subscribers to move to the ACMEv2 protocol.

Today we are announcing an end of life plan for ACMEv1.

In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected). The intention is to induce client errors that might encourage subscribers to update to clients or configurations that use ACMEv2. Renewal failures should be limited since new domain validations will already be disabled and we recommend renewing certificates 30 days before they expire.

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

We would like to remind people reading this about an upcoming change to our ACMEv2 support. Starting in November 2020 we will no longer allow unauthenticated resource GETs when using ACMEv2 1.2k.

--　自動翻訳 --
証明書発行と管理のためのLetのEncryptにより用いられる最初のプロトコルは、ACMEv1と呼ばれています。
2018年3月に、我々は、ACMEv2（RFC 8555 285として今日確定したことにマッチするプロトコルのより新しいバージョン）に対する支持を導入しました。
我々は、加入者がACMEv2プロトコルへ移るのを奨励していました。

今日、我々はACMEv1のライフプランの終わりを発表しています。

2019年11月に、我々はACMEv1 APIエンドポイントで新しい口座登録を許すのを止めます。
既存の口座は、正常に機能し続けます。

2020年6月に、我々は、ACMEv1を通して確認する新しい領域を許すのを止めます。

2021年の初めにから、24時間（ほんの1ヵ月につき1回（OCSPサービスは影響を受けません）しかでなく）の期間の間、我々はACMEv1発行と更新を時折抑制します。
意向は、加入者がクライアントに更新するのを奨励するかもしれないクライアント・エラーまたはACMEv2を使う構成を誘発することです。
新しい領域確認がすでに使用不能な時から、更新失敗は制限されなければなりません、そして、我々は彼らが息が絶える30日前に証明書を新しくすることを勧めます。

2021年6月に、我々は、LetのEncrypt証明書を得る現実的な方法として、ACMEv1を完全に働かなくします。

ACMEv2支持に近づく変化についてこれを読んでいる人々に思い出させたいです。
2020年11月に始まって、ACMEv2 1.2kを使うとき、我々は証明されてない資源GETsをもはや許しません。

-- ここまで --

という事らしいです。
そしてリンク先を見ると
https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380
During a final round of review within the IETF before the creation of RFC 8555 17 the draft ACME protocol was updated to replace unauthenticated GET requests to resources (certificates, orders, authorizations and challenges) with an authenticated POST carrying a special empty JWS body (called a “POST-as-GET” request 91 by RFC 8555).

We have added support for the POST-as-GET construction for certificates, orders, authorizations and challenges to the ACME v2 API while simultaneously allowing legacy GET requests to these resources. Clients may begin sending POST-as-GET requests to the staging and production V2 API as of October 25th, 2018.

On November 1st, 2019 we will remove support for unauthenticated GETs from the staging V2 API, requiring client support for POST-as-GET.

On November 1st, 2020 (one year later) we will remove support for unauthenticated GETs from the production V2 API.

ACME v2 Clients that do not have support for POST-as-GET will not be able to issue or renew certificates in the staging and production environments after the above deprecation dates.

In addition to the V2 staging API ACME client developers are encouraged to use the Pebble test server 70 version 2.x.x or later to test client POST-as-GET support. Please see the “GET and POST-as-GET Requests” 91 section of RFC 8555 for more information.

-- 自動翻訳 --
RFC 8555 17の作成の前のIETF内のチェックの最終回の間に、特別な空のJWS体（RFC 8555による「GETとしてのPOST」要請91と呼ばれる）を運んでいる資源（証明書、命令、認可と挑戦）への証明されてないGET要請を認証されたPOSTと入れ替えるために、草案ACMEプロトコルは更新されました。

同時にこれらの資源にレガシーGET要請を許す間、我々はGETとしてのPOST建設に対する支持を証明書、命令、認可とACME v2 APIへの挑戦のために加えました。
クライアントは、2018年10月25日現在、GETとしてのPOST要請を足がかりと生産V2 APIに送信し始めるかもしれません。

2019年11月1日に、我々は足がかりV2 APIから証明されてないGETsに対する支持を取り除きます。そして、GETとしてのPOSTに対するクライアント支持を必要とします。

2020年11月1日（1年後で）に、我々は生産V2 APIから証明されてないGETsに対する支持を取り除きます。

出るか、上記の非難日付以後足がかりと生産環境で証明書を新しくすることが、GETとしてのPOSTに対する支持をしないACME v2 Clientsは、できません。

APIを示しているV2に加えて、Pebbleテスト・サーバー70バージョン2.x.xを使うか、後でGETとしてのクライアントPOSTサポートをテストするのを、ACMEクライアント開発者は奨励されます。
詳細はRFC 8555の「GETとGETとしてのPOST Requests」91セクションを見てください。

-- ここまで --

てことで pebble test server が
https://github.com/letsencrypt/pebble
ここにリンクしてます。
ここには
Pebble is NOT INTENDED FOR PRODUCTION USE. Pebble is for testing only.
って書かれていて、じゃどうしろというんだろうか？

ご存じの方いらっしゃいますか？
-- 
山本 伸一 <beniya@xxxxxxxxxxxxxx>