ウィスキー、シガー、パイプをこよなく愛する大栗です。 最近ブラウザから簡単に証明書を発行できる ZeroSSL というサービスで証明書を発行したことがあったのでまとめてみます。 ZeroSSL （8月21日追記） ACME 経由であれば無制限に無料で証明書を発行できる旨を追記しました ZeroSSL 無料で SSL/TLS 証明書を発行できるサービスと言うと Let's Encrypt を利用されている方が多いと思います。2023年8月時点で Let's Encrypt が発行している有効な証明書は2億8000万を超えています1。Let’s Encrypt は素晴らしいサービスですが、単一障害点になっていることに警鐘を鳴らしているセキュリティ研究者もいます2。別の選択肢として ZeroSSL を紹介しています。 Let's Encrypt では certbot の様なコマンドを使用して S
無料でウェブサーバー向けのSSL/TLS証明書を発行している認証局Let's Encryptは、自身を信頼していない端末にも信頼される証明書を発行できるようにIdenTrustからクロス署名を受けていましたが、Let's Encryptを信頼する端末が増加したことを受けて、2024年にIdenTrustからのクロス署名を廃止すると発表しました。 Shortening the Let's Encrypt Chain of Trust - Let's Encrypt https://letsencrypt.org/2023/07/10/cross-sign-expiration.html SSL/TLSを使うと、通信において「通信相手が偽物にすり替わっていないか」「途中でデータが改ざんされていないか」などを確認できたり、通信内容を暗号化することで盗聴されるのを防止できたりするというメリットがあ
これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef
もともと python3-certbot-apache で設定していたのを、ワイルドカード証明書に変更したときの記録。 certbotのインストールと昔の設定 コマンド履歴をみるとこんな感じだったらしい。 sudo apt install certbot python3-certbot-apache sudo certbot --apache sudo certbot renew --dry-run certbotでワイルドカード証明書を取得 Let's Encryptでワイルドカード証明書を取得する | クラウドのエスエスアイ・ラボ を参考に sudo certbot certonly \ --manual \ --cert-name fuktommy.com \ --preferred-challenges dns \ -d "*.fuktommy.com" \ -d fuktommy
未だに迷うのでまとめる。 どのオプションを使うべきか？ 既存のウェブサーバーをそのまま使う やり方 /.well-known/acme-challenge へのアクセスを設定する 特徴 やり方 standalone なウェブサーバーを建てる 特徴 DNS で TXT レコードを貼る方法 特徴 やり方 コマンドについて 発行したあとの期限の確認方法 まず、大きく分けていくつか方法がある。 既存のウェブサーバーをそのまま使う方法(nginx, apache) 発行時にのみウェブサーバーを立てる方法(standalone) DNS のレコードを設定して対応する方法(manual) 一時ファイルを設置する方法(webroot, manual) どのオプションを使うべきか？ 結論から書くと、certonly で使うべきオプションは以下のとおり --nginx, --apache --manual(h
「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証
Let’s Encryptのルート証明書とは？ Let's Encryptを運営している非営利団体のISRG（Internet Security Research Group）は2014年に設立された新しい認証局です。もちろん、当時は設立されたばかりなのでISRGのルート証明書は様々な端末にインストールされていませんでした。そのため、別の認証局であるIden Trustが2000年に発行した「DST Root X3」というルート証明書を利用し、クロス署名された中間CA証明書を現在も利用しています。 この間（2014年～現在まで）ISRGは何をしていたかというと、各OS（Windows、Mac、Android等）やMozilla（Firefoxブラウザの開発元）に対して、自社のルート証明書である「ISRG Root X1」をインストールしてもらうようにお願いをして、徐々にインストール済み端末
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
■ KnotDNS _ 昨年の IW2018 の資料が公開されたようで。 _ 自分は Knot DNS の話をしたですよ。DNSSEC やりたいけどあんなの運用まわらん、とか、Let's Encrypt で DNS 認証させたいけど自動化できなくてめんどくさい、とか言ってる人いればぜひ Knot を使ってみてくださいませ。自動化できるよ。まあ、BIND でできないわけじゃないけど。いきない Knot に乗り換えるのが怖くても、資料にあるように、BIND やら NSD やら使い慣れたものを前段、後段に置いて三段構成にすれば、Knot をほとんど意識せず、これまでとほとんど変わらない感覚で自動化できるよ。 _ 資料に書こうか迷ったけど結局やめておいたネタ。 _ 資料では Let's Encrypt の dns-01 認証による証明書取得を自動化する方法について触れてるけど、そうはいってもうちの
2019.2.5システム開発 システムエンジニア 大貫 晃一 2021年8月1日「マリンロード」は「インソースマーケティングデザイン」へ社名を変更いたしました ビジネスで、無料のSSL証明書 Let’s Encrypt を使用するべきか こんにちは、システムエンジニアの大貫です。 2年前に無料のSSL証明書について、触れましたが、セキュリティ性の高いHTTPSでの通信を普及させることを目的として「Let’s Encrypt」による無料のSSL証明書の発行ができるようになりました。 その後の傾向を調べてみましたが、なんと「Let’s Encrypt」は無料で発行できるということもあってか、フィッシングサイトでも年々SSL化が、多く利用されるようになり、フィッシングサイトの実に50%くらいが、SSL証明書を導入しているとの記事がありました。 49 Percent of Phishing Sit
社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 2018年7月はWeb業界にとって記憶に残る日になるでしょう。httpsが標準となった日として。 これまでWebサイトへのアクセスにはhttpを利用するのが通常で、安全性が求められる場合にはhttpsを利用すると考えられてきましたが、これからはhttpsを使うのが当たり前になっていくでしょう。この流れを強力にけん引しているのは、保守的な我が国においてもトップシェアブラウザとなったChromeを擁するGoogleであることはご存知の通りです。これまではhttpでのアクセスには特に表記はなく、httpsでアクセスすると「保
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat
2018年03月13日に本番環境の ACME v2 エンドポイントが使用可能になりました。 エンドユーザーは、ACME v2 互換クライアントで下記の Directory URL を用いることで、本番環境で使用できる SSL/TLS サーバ証明書（ブラウザで信頼済みとして扱われる証明書）を発行することができます。 https://acme-v02.api.letsencrypt.org/directory ※このエンドポイントにアクセスする際には、ACME v2 に対応したクライアント を使用する必要があります。ACME v2 Compatible Clients をご確認ください。 ※Certbot クライアントは、Version 0.22.0 以上が ACME v2 とワイルドカード証明書に対応しています。 背景情報 Let's Encrypt Community Support の過
We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates. ACMEv2 is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry e
Let’s Encrypt の証明書の自動更新が失敗しているサーバーがあって、原因を調べたら AAAA レコードに設定している IPv6 アドレスが間違っていたのが原因でした。 環境 Debian GNU/Linux 8.8 (jessie) certbot 0.10.2-1~bpo8+1 さくらインターネットの VPS で IPv6 を使用 (過去に tun6rd を使っていた) 現象 2016-03-29 に現在のサーバーに移動した時に A レコードを書き換えただけではなく、追加で tun6rd の頃の IPv6 アドレスを AAAA レコードに設定してしまいました。 別の IPv6 アドレスを設定しているサーバーからの接続に時間がかかるという現象が発生していたものの、原因がわからず、ずっとそのままの状態でした。 StartCom の証明書が事実上使えなくなってしまったので、 2016
概要 無料でSSL証明書が使えるということで個人で使ったり、 ローカルの開発環境にSSLを入れられると便利だなと思い、調べてみる。 ＜検証環境＞ 余っているドメインがある（どこにも使ってない） 主にローカル環境で開発をしている 最近HTTPSのサイトが多くなってきたので、オレオレ証明書ではなく正規の証明書を使いたい。 Let's Encryptの認証方法 Let’s Encryptで証明書の取得を行う場合、以下の方法などで、 ドメインを認証する必要があるようです。 HTTPによるドメイン認証 (HTTP-01) HTTPSによるドメイン認証 (TLS-SNI-01) DNSによるドメイン認証 (DNS-01) 今回は、公開しているサイトではないので、以下の方法を検討する。 ＜DNSによるドメインを認証を方法 (DNS-01)＞ 認証対象のドメインのサブドメインのTXTレコードにトークンが設
2016.09.23 Let's EncryptがVerisignと棲み分けできる理由: SSL証明書の「DV、OV、EV」とは何か こんにちは、hachi8833です。 無料でSSL証明書を発行してくれるLet's Encryptが大人気を博していますが、Verisignを始めとする有料の認証局（CA）はやきもきしていたり刺客を差し向けていたりしないのでしょうか？ そのあたりを弊社インフラエンジニアのyamasitaさん、そしておなじみmorimorihogeさんとbabaさんが解説してくれました。 証明書のランク分け: DV、OV、EV SSLなどで使われる証明書の種類として、DV（Domain Validation）、OV（Organization Validation）、EV（Extended Validation）の3つがあります。 ざっくり言うと、後者になるほど値段も張り、取得
現行の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のプロバイダによる、証明書の発行やそれにまつわるリクエストへの量的な制限とな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
