ハトネコエ Web がくしゅうちょう

プログラミングやサーバー関連、チームマネジメントなど得た技術のまとめ

http2 設定で cert renew に失敗

sudo cert renew --dry-run

に失敗。

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/xx.yy.com.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for xx.yy.com
Waiting for verification...
Cleaning up challenges

Attempting to renew cert (xx.yy.com) from /etc/letsencrypt/renewal/xx.yy.com.conf produced an unexpected error: 
Failed authorization procedure. xx.yy.com (http-01): 
urn:ietf:params:acme:error:connection :: 
The server could not connect to the client to verify the domain :: 
Fetching http://xx.yy.com/.well-known/acme-challenge/2vTuPTMugzS_MiYSwr_zycQahYwUOjIb3JngrZ2D46I: 
Error getting validation data. Skipping.

今まで何度見たことか……。

nginx のアクセスログにアクセス履歴が残ってなかったので、
「ファイルの作成に失敗……? 権限周り……?」と疑ったのですが、そうではなく、
結論としては、gRPC用に 80 番ポートにも http2 設定を付けていたこと。

つまり

server {
    listen 80 http2;
    listen [::]:80 http2;
    server_name xx.yy.com;

となっているのを

server {
    listen 80;
    listen [::]:80;
    server_name xx.yy.com;

に戻してあげたら上手くいきました。

謎なのが、この xx.yy.com の認証だけでなくて yy.com や zz.yy.com なども失敗していたのですが、
この xx.yy.com 用の設定を直してあげただけで他も成功するようになったこと。

なんなの? 連帯責任なの・・・??

http2 設定を消したことによって 80 番での gRPC の通信ができなくなったけど、
まあ 443 番の方を使うのでそんなに問題は無しですね。

ところで、HTTP/2 って SSL/TLS 通信*1が必須だと思っていたので、
80 番ポートに http2 設定、というのを見て最初は「?」と思ったのですが、
平文(非TLS)の HTTP/2 通信も存在するんですね。

ただ、クライアント側(受け取り手)のサポートがあまりないので、
実質的には SSL/TLS 必須と。そういうことのようです。

基本的にサポートされているのはTLSを使用するh2のみで、多くのWebブラウザでは平文でやり取りを行うh2cについては未サポートとなっている。

https://knowledge.sakura.ad.jp/7734/ より引用 )

逆に言えば、送信側はなにも制限がないので、nginx の80番ポートに http2 設定を書けるのは何もおかしくはないし、
gRPC 用のクライアントが平文の HTTP/2 通信に対応しているのなら、そことやり取りできるわけですね。

*1:厳密にはTLS通信だが、SSL通信という言い方も歴史的に残っているのでこのように書いている