制限と仕様からLet's Encrypt(ACMEv1)の話 - Qiita
現行のACMEv1を使ったLet's Encryptのお話。 (https://letsencrypt.org) V1は終わりましたが、V2でも概ね同じです。一応V2はひとつ制限が追加されてます、追記の3を参照。 個人が手持ちのドメインで利用するにはあまり気にすることもないですが、何度も証明書を発行しようとすると制限に引っかかってくることがあります。 https://letsencrypt.org/docs/rate-limits/ 先日Encryptを少し多めにLet'sした機会があったので、その時に色々気を使ったことをまとめておきます。 Let's Encryptにかかる制限(rate-limits) といっても、(ドメインの所有さえ確認できれば)ACMEの仕様としてかかる制限はありません。 ほとんどはACMEのプロバイダによる、証明書の発行やそれにまつわるリクエストへの量的な制限とな
Let's EncryptのDNS認証を試してみる - Qiita
TL;DR HTTP方式とほぼ同じでいけます。 違いは認証用Tokenが反映されるまでにインターバルがある事くらいでした。 自分でDNSを引いて認証用Tokenが反映されているのを確認した後、VerifyすればOKです。 作ったものは https://github.com/nak1114/letsencrypt-dns01/ に置いておきます。 きっかけ Let's Encryptが18年1月にACME-v2になり、Wildcard SSL証明書を発行可能になるとアナウンスがあったがきっかけです。 intra.example.comのようなあからさまにイントラ用のDomainでも今までは外に向けて公開していました。Wildcardに出来るのならこういうのを隠蔽できるだろうと、ACME-v1だけど一足先にDNS認証に切り替えてみようと思いました。 権威サーバの保守の方が面倒そうだけど、とりあ
JavaScript モジュールの現状 | POSTD
(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD — どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権
Next 3.0 Preview: Static Exports and Dynamic Imports – Vercel
On the heels of our announcement of free static deployments earlier today, we are excited to introduce a beta release of the upcoming Next.js 3.0, featuring next export, dynamic components and various bugfixes. Next.js allows you to write React applications with server-rendering, automatic code-splitting, built-in component CSS with one command. To get started, populate pages/my-route.js directory
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
