LoginSignup
34
30

More than 5 years have passed since last update.

@MahoTakara(Maho Takara)

コンテナでHTTPSを利用するには （自己署名証明書、自営CA、 公的CAなどからの証明書の取得）

Last updated at Posted at 2018-10-11

KubernetesでHTTPSを利用する方法として、イングレスに証明書をセットすることで、コンテナやポッドの設定を追加せずに、HTTPSを利用できるようになります。 しかし、パフォーマンスやスケールの観点では、イングレスコントローラーに負荷が集中するために、ポッドのレプリカ数を増やしても、思ったように性能が出せないなどの課題に直面することになります。 (IBM Cloudでは ALBと呼ばれています、) そこで、外部のロードバランサーやイングレスにも頼らず、コンテナの中で、TLS暗号を終端して、スケールさせるという方法について、検討する中で、テスト中にサーバー証明書で困ったので、書き残すことにしました。

この記事は、NginxのコンテナでHTTPSでサービスを公開するには、すなわち、TLS暗号を利用する方法のメモです。TLS暗号のためには、証明書が必要で、次の３つの方法で作成することができます。

  • 自己署名証明書
  • 自営の認証局(CA)による証明書
  • 公的な認証局(CA)の発行した証明書

自己署名証明書は、費用も発生せずに、簡単に生成できて、開発やテストには便利だと思います。 自営の認証局による証明書は、CAの証明書をクライアントに追加すれば、警告を発生させずにTLS暗号を確率できるため、チーム内や組織での限られた範囲での利用には、セキュリティ上のリスクを許容できれば、コストが掛からないの適する様に思います。そして、大規模な組織内利用や商用運転では、費用が発生しますが、公的な認証局に証明書署名要求(CSR)を提出して、第三者が確認できる公式の証明書を利用するのが良いと思います。

DockerコンテナのNginxを利用する場合のこの３つの証明書の利用法について、メモとして残しておきたいと思います。

CSR(証明書署名要求)の発行

証明書に署名してもらうために、証明書署名要求(CSR)を作成します。それに前もって、サーバー鍵を作成してます。 この鍵ファイルは、NginxのTLS/SSL設定にも必要なので、大切に保存しておきます。

$ openssl genrsa -des3 -out server.key.encrypted 2048
Generating RSA private key, 2048 bit long modulus
...........................................................................................+++
.............................................................................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:qwerty123
Verifying - Enter pass phrase for server.key:qwerty123

TLS暗号設定の際に、暗号化されない鍵ファイルが必要なので、ここで復号しておきます。

$ openssl rsa -in server.key.encrypted -out server.key
Enter pass phrase for server.key:qwerty123
writing RSA key

これで、暗号化ありと、平文の鍵ファイルが出来たことになります。

  • server.key
  • server.key.encrypted

次に、証明書署名要求(CSR)を作成します。-subjに対話型で入力する部分をセットしてあるので、コマンドは以下の１行で作成が完了します。-subjを省略すると、対話型で必要項目をインプットするようになります。

$ openssl req -new -key server.key -out server.csr -subj "/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign/CN=www.mahotakara.org"

-subj の項目説明をいかに書きます。 CN以外は省略可能ですが、CSRを公的機関へ提出して署名を求める場合には、承認を得られるように正しくインプットする必要があります。

  • C 国コード、日本はJPです。
  • ST 州ですが、日本国では県に相当するので、Tokyoをセットします。
  • L 市町村をインプットします。 例ではNihombashとしていますが、事業所などの住所をセットします。
  • O 会社名をインプットします。
  • OU 会社の事業部など、部課などの組織の情報です。
  • CN ドメイン名をセットします。

CSRからの自己署名証明書の作成

CSRを利用して、自己署名証明書も作成できます。次のコマンドを実行することで、自己署名証明書ファイル server.crt が出力されます。ここで出力したファイルと、CSRを作る際に作成したserver.keyとセットで、Nginx のTLS暗号の設定に利用できます。

$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=JP/ST=Tokyo/L=Nihonbash/O=TakaraSign/CN=www.mahotakara.com
Getting Private key

一つのコマンドで自己署名証明書を発行する方法

最初から自己署名証明書しか作らないのであれば、次のコマンドで一発で、自己署名証明書を作成できます。鍵 selfsigned.key と証明書 selfsigned.crt の両方を得ることができます。 この二つを利用して、NginxのTLS暗号の設定ができます。

 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout selfsigned.key -out selfsigned.crt -subj "/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign/CN=www.mahotakara.org"

自営の認証局の構築と署名

自営の認証局を構築して、CSRから証明書を作成することができます。

自営の認証局を構築するのは、次のステップになります。

  • Linux仮想サーバーを準備
  • 専用のディレクトリとサブディレクトリを作成
  • 設定ファイルのコピー
  • 環境変数をセット
  • 認証局の自己署名証明書作成

次の手順によって、Ubuntuの仮想サーバーを起動しました。

$ mkdir ca
$ cd ca
$ vagrant init ubuntu/xenial64
$ vagrant up
$ vagrant ssh

専用のディレクトリとサブディレクトリを作成

mkdir /home/vagrant/private_ca
cd /home/vagrant/private_ca
mkdir certs private
chmod g-rwx,o-rwx private
echo '01' > serial
touch index.txt
mkdir newcerts

Ubuntu Linux にインストールされた OpenSSL の 設定ファイルを、プライベート認証局のディレクトリにコピーします。そして、バックアップをとって、編集します。

cp /etc/ssl/openssl.cnf .
cp openssl.cnf openssl.cnf.org
vi openssl.cnf

認証局の編集箇所は以下の通りです。 次のdiffの通り、dirを絶対パスに変更しただけです。

$ diff -c openssl.cnf openssl.cnf.org
*** openssl.cnf 2018-10-10 13:55:33.966941528 +0000
--- openssl.cnf.org 2018-10-10 11:47:25.368371281 +0000
***************
*** 39,45 ****
  ####################################################################
  [ CA_default ]

! dir       = /home/vagrant/private_ca # Where everything is kept
  certs     = $dir/certs        # Where the issued certs are kept
  crl_dir       = $dir/crl      # Where the issued crl are kept
  database  = $dir/index.txt    # database index file.
--- 39,45 ----
  ####################################################################
  [ CA_default ]

! dir       = ./demoCA      # Where everything is kept
  certs     = $dir/certs        # Where the issued certs are kept
  crl_dir       = $dir/crl      # Where the issued crl are kept
  database  = $dir/index.txt    # database index file.
***************
*** 47,53 ****
                    # several ctificates with same subject.
  new_certs_dir = $dir/newcerts     # default place for new certs.

! certificate   = $certs/cacert.pem     # The CA certificate
  serial        = $dir/serial       # The current serial number
  crlnumber = $dir/crlnumber    # the current crl number
                    # must be commented out to leave a V1 CRL
--- 47,53 ----
                    # several ctificates with same subject.
  new_certs_dir = $dir/newcerts     # default place for new certs.

! certificate   = $dir/cacert.pem   # The CA certificate
  serial        = $dir/serial       # The current serial number
  crlnumber = $dir/crlnumber    # the current crl number
                    # must be commented out to leave a V1 CRL

opensslコマンドの設定ファイルの参照先が、専用ディレクトリの設定ファイルに向くように、環境変数をセットします。

export OPENSSL_CONF=`pwd`/openssl.cnf

自己署名付きルート証明書を作成します。 前述で作成したディレクトリへ保存されるように出力先をセットしていますので、移動は必要ありません。

openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out certs/cacert.pem -days 3650 -subj "/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign"

以上で、自営認証局の作成が完了しました。

自営の認証局による署名

前述で作成したCSRを -in のパスに設定して、実行すると、newcertの下に、01.pemというファイル名で証明書が作成されます。

openssl ca -in /vagrant/csr/server.csr

この01.pem と CSR作成に利用したserver.keyを利用して、Nginx のTLS暗号の設定に利用できます。

公的認証局へのリクエスト

無料の証明書もたくさんありますが、https://www.rapidsslonline.com/ では、 $17.95/year で証明書を発行してくれます。 ただし、ドメインを持っている必要があり、そのドメインでメールを受信できなければなりません。

スクリーンショット 2018-10-10 23.35.39.png

この画面に従って、手続きを進めて、最初に作ったCSRをコピーとペーストすることで、申し込み完了です。注文が確定すると、確認メールが指定ドメインのメールサーバーのadminに送られてきます。 このドメインでメールを受け取れるように、メールサーバーを設定しておく必要があります。これなら、無料で利用できる認証局 Let's Encrypt (https://letsencrypt.org/) を利用するのが良い感じもしますね。

証明書の受け取り

RapidSSLでは、メールで証明書を送ってくれます。 受けたメールの証明書をコピー＆ペーストして、NginxのTLS暗号の設定に利用します。公式認証局の発行する証明書は、中間証明書とサーバー証明書の２つになります。これらを下記のようにマージした一つのファイルとして、設定に利用します。

cat server.crt
-----BEGIN CERTIFICATE-----
MIIFyzCCBLOgAwIBAgIQDOo8pwDgfPf+wp26pXdBKTANBgkqhkiG9w0BAQsFADBe
<中略>
KVlifck5jZiVV3Lktk2/4UK3JpLJPBaUZQDPA37roX3J2Xb0TbUczSVT7tPyCOg=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEsTCCA5mgAwIBAgIQCKWiRs1LXIyD1wK0u6tTSTANBgkqhkiG9w0BAQsFADBh
<中略>
ysNyq0jEDQTkfa2pjmuWtMCNbBnhFXBYejfubIhaUbEv2FOQB3dCav+FPg5eEveX
TVyMnGo=
-----END CERTIFICATE-----

NginxコンテナのHTTPS化

まず、コンテナのNginxでTLS暗号の動作を確認します。鍵ファイルと証明書ファイルのファイル名は、適当に修正をお願いします。

$ tree nginx-conf/
nginx-conf/
└── nginx.conf

0 directories, 1 file

$ cat nginx-conf/nginx.conf 
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
server {
    listen 443 ssl;
    server_name www.takara.com;
    ssl_certificate /etc/tls/nginx-selfsigned.crt;
    ssl_certificate_key /etc/tls/nginx-selfsigned.key;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

imac:nginx-develop maho$ tree tls
tls
├── nginx-selfsigned.crt
└── nginx-selfsigned.key

コンテナの実行の軌道で、-v に設定ファイルと証明書のディレクトリをセットします。 -v のローカルのパスは、絶対パスなので、pwdを置いて置換されるようにします。

docker run -d --name web -v `pwd`/nginx-conf:/etc/nginx/conf.d -v `pwd`/tls:/etc/tls  -p 9443:443 nginx

コンテナのアクセステストには、次のようにします。公的認証局の証明書の場合は -H ドメイン名　の指定は必須です。

curl -k -H 'www.takara.com' https://127.0.0.1:9443

KubernetesのポッドのHTTPS化

Kuberentesで設定する場合は、Nginxの設定はコンフィグマップに、証明書はシークレットに保存します。

シークレット作成では、オプションにtlsを設定すると、TLS暗号用に証明書と鍵ファイルを登録するオプションを利用できます。この設定で登録した場合、ファイル名が決まってしまうので、コンフィグマップのnginx.confに記述された鍵と証明書ファイルのパスを変更しなければなりません。

$ kubectl create secret tls tls-cert --cert=tls/nginx-selfsigned.crt --key=tls/nginx-selfsigned.key
secret/tls-cert created

シークレットの確認です。ファイル名を確認しておき、Nginxの設定ファイルと矛盾が無いようにします。

$ kubectl describe secret tls-cert
Name:         tls-cert
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/tls

Data
====
tls.crt:  1025 bytes
tls.key:  1704 bytes

コンフィグマップの作成は、ディレクトリを指定して、ディレクトリ内にある全てのファイルを、コンフィグマップの設定として保存します。

$ kubectl create configmap nginx-conf --from-file=nginx-conf
configmap/nginx-conf created

コンフィグマップの登録確認結果です。 get の変わりに describeを置くと、ファイルの中身まで表示します。

$ kubectl get configmap nginx-conf
NAME         DATA      AGE
nginx-conf   1         10s

デプロイメントのマニフェストの作成します。 コンフィグマップとシークレットは、コンテナに対して、ボリュームとしてマウントします。マウントポイントは、コンテナイメージの中の設定ファイルの位置を調べておき、決めています。

## デプロイメント 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-x
spec:
  replicas: 3
  selector:           # これは deployment - pod 対応用
    matchLabels:
      app: web-x      # ポッドと一致するべきラベル
  template:           # ここからポッド・テンプレート
    metadata:
      labels:
        app: web-x    # ポッドのラベル
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - protocol: TCP
          containerPort: 443
        volumeMounts:
        - name: nginx-conf   #コンフィグマップのマウント
          mountPath: /etc/nginx/conf.d
        - name: tls-cert     #シークレットのマウント
          mountPath: /etc/tls
      volumes:
      - name: nginx-conf   # コンフィグマップ
        configMap:
          name: nginx-conf
      - name: tls-cert     # シークレット
        secret:
          secretName: cert

サービスロードバランサーのマニフェストです。 IKS (IBM Cloud Kubernetes Service)のマニフェストですが、他のクラウドベンダーでも使えると思います。 もしかしたら、annotation の追加が必要かもしれませんが。。。

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web-x
  ports:
  - name: webserver
    protocol: TCP
    port: 443
  type: LoadBalancer

Kuberentesへのデプロイと、アクセステストです。 この場合は、もちろん、ロードバランサーのパブリックIPアドレスはDNS登録されている必要があります。

$ kubectl apply -f svc-lb-x.yml
service/web-svc changed
$ kubectl apply -f apl.yml
deployment.apps/web-x created

$ kubectl get po
NAME                     READY     STATUS    RESTARTS   AGE
web-x-6b5787bf87-jh6v2   1/1       Running   0          7s
web-x-6b5787bf87-l9nmc   1/1       Running   0          7s
web-x-6b5787bf87-qtv8s   1/1       Running   0          7s

$ curl https://www.mahotakara.online/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<以下省略>

opensslで検証する方法

作成または取得した証明書を検証するには、SSL/TLS server programとSSL/TLS client programを利用することが出来ます。それには、サーバー相当のコマンドに、サーバー証明書と鍵をセットして、クライアント相当からアクセスして、クライアントの表示を確認します。

-accept:ポート番号、-WWW:ウェブサーバーで接続まち、-cert サーバー証明書、-key 鍵 をセットして、クライアントからの接続待ちにします。

openssl s_server -accept 10443 -cert server.crt -key server.key  -WWW

公的機関の認証局の場合には、-CAfileオプションは不要です。 自営認証局では、自営認証局の証明書をセットします。

openssl s_client -connect  127.0.0.1:10443  -CAfile cacert.pem

実行結果1 証明書エラー

自営認証局の証明書（自己署名証明書)のサーバーに接続した場合の結果です。 CONNECTED以降の行で、ベリファイエラー(verify error）が発生していることがわかります。 

$ openssl s_client -connect  127.0.0.1:10443 
CONNECTED(00000003)
depth=0 C = JP, ST = Tokyo, O = TakaraSign, CN = helloworld-python.default.mahotakara.online
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = JP, ST = Tokyo, O = TakaraSign, CN = helloworld-python.default.mahotakara.online
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = JP, ST = Tokyo, O = TakaraSign, CN = helloworld-python.default.mahotakara.online
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=JP/ST=Tokyo/O=TakaraSign/CN=helloworld-python.default.mahotakara.online
   i:/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDpDCCAoygAwIBAgIBAjANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJKUDEO
MAwGA1UECAwFVG9reW8xEjAQBgNVBAcMCU5paG9tYmFzaDETMBEGA1UECgwKVGFr
YXJhU2lnbjAeFw0xOTAxMDYxMjEwMTRaFw0yMDAxMDYxMjEwMTRaMGgxCzAJBgNV
BAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzETMBEGA1UECgwKVGFrYXJhU2lnbjE0MDIG
A1UEAwwraGVsbG93b3JsZC1weXRob24uZGVmYXVsdC5tYWhvdGFrYXJhLm9ubGlu
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK4eOyHmT8pXJwBwPtN1
SGmmwvlbVGLhjg1sFymzyeTCwuDpLBvGXvEHrrEyvk6mussBOkwPH3flGidtzjo8
F8aeIEGRH2iy0NrIV/ZG2md6yyjbDMa/v2+uwG5Ifi5JIVdDHljTDcb8AbhVJWWe
qvnauy5uriAyfi/8DVJJ8LSYWzNbbN9pmuEgOdfwS+bTiPVV2wHEaVFoLp1l3C1+
iaR3flU/bOuAQALpkJw32+MND6paLk8wUGVBecvEmM34s11gb9lPk+Othl3A3FOU
FluiLbeyzNtUCElDaPH/ekw1zj4diabuzojDTevTlHQPYJVPKOQbt9VMvC7S+MsT
+gMCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH
ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHi+OnGkmdqu3gEHBKSEWSC0
kinyMB8GA1UdIwQYMBaAFPa/N2AAzf/QrQ5qkSwpriQAM188MA0GCSqGSIb3DQEB
CwUAA4IBAQC3qp3+ur9SWFrVKaM5thlOKuv7Pnp38qFaEoBWmAw+5ng88svfKd6w
ZVcENxCegHUBhlJ3NcVdIbVViYa+GoLLKCukAy2CWPKmRAfrWu7B8L4EMAR35B81
K1B2y+RBgWarpEpNS3sGTAJa5Rf9jReDv8BubLIYB0nIHBovCvifmfy9up9Qmoab
8JILaUOn+X6Wgepsa9Q7SfHRBr3rXu0P45ZuXPQfk+bgPW2dx3pkAZEMjZKsoWNf
ue2GY9AaxCjyeJbYUZK4EqHk9ZndzTo78KE9DkIUmQSgdvmknb6PZFv7Y5GrI4AG
T9dJR4PayBw8GWljPmoKmRTcYo98dWZj
-----END CERTIFICATE-----
subject=/C=JP/ST=Tokyo/O=TakaraSign/CN=helloworld-python.default.mahotakara.online
issuer=/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign
---
No client certificate CA names sent
---
SSL handshake has read 1582 bytes and written 436 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: 0342B001155C8B4FFA318E643D0CD33F34401D7B54BA69044586D133CED8EAF9
    Session-ID-ctx: 
    Master-Key: 494C6484D91A4CE7809BFE7492A8054EBB8C6DF17390A21461960F09FABD545DBE2304FED097B4D35B0FA9C4C73E25B7
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 3c 0a cd ca a1 ad 68 20-e6 72 11 9a ca d9 d7 9a   <.....h .r......
    0010 - 69 be d6 be ea b1 d0 a4-0a 8c b7 33 6e 2a e7 70   i..........3n*.p
    0020 - b6 6b 64 19 29 62 54 54-b0 f4 f8 3f 84 8a 23 b0   .kd.)bTT...?..#.
    0030 - a2 d5 e0 ce db 53 71 b3-65 20 13 b8 7c 70 21 00   .....Sq.e ..|p!.
    0040 - 15 bd a2 4e 59 8b 6b c9-32 8e 29 d6 a8 72 c3 06   ...NY.k.2.)..r..
    0050 - a6 6b ae 61 d3 b7 75 c7-2c 12 eb 11 53 fd 59 d2   .k.a..u.,...S.Y.
    0060 - a8 d2 21 46 5a 4e 8f 65-37 83 2b 5b bb 82 22 47   ..!FZN.e7.+[.."G
    0070 - 21 a5 7e b1 c9 86 ac 0c-30 89 53 25 03 8c ab d7   !.~.....0.S%....
    0080 - 82 1e 20 89 77 60 6b 0d-6a 82 4f 91 00 9e 30 65   .. .w`k.j.O...0e
    0090 - 1f 4f c9 37 e0 e3 40 f0-a7 01 2b 1e 7e d0 2f de   .O.7..@...+.~./.

    Start Time: 1546781746
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

実行結果2 成功例

こちらは、自営認証局の証明書ファイルを設定して、サーバーへアクセスします。 先ほどの例と異なり、ベリファイエラーが無くなり、return 1 となっています。 これで証明書に署名した認証局の身元か確認できたことになります。

$ openssl s_client -connect  127.0.0.1:10443  -CAfile cacert.pem 
CONNECTED(00000003)
depth=1 C = JP, ST = Tokyo, L = Nihombash, O = TakaraSign
verify return:1
depth=0 C = JP, ST = Tokyo, O = TakaraSign, CN = helloworld-python.default.mahotakara.online
verify return:1
---
Certificate chain
 0 s:/C=JP/ST=Tokyo/O=TakaraSign/CN=helloworld-python.default.mahotakara.online
   i:/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDpDCCAoygAwIBAgIBAjANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJKUDEO
MAwGA1UECAwFVG9reW8xEjAQBgNVBAcMCU5paG9tYmFzaDETMBEGA1UECgwKVGFr
YXJhU2lnbjAeFw0xOTAxMDYxMjEwMTRaFw0yMDAxMDYxMjEwMTRaMGgxCzAJBgNV
BAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzETMBEGA1UECgwKVGFrYXJhU2lnbjE0MDIG
A1UEAwwraGVsbG93b3JsZC1weXRob24uZGVmYXVsdC5tYWhvdGFrYXJhLm9ubGlu
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK4eOyHmT8pXJwBwPtN1
SGmmwvlbVGLhjg1sFymzyeTCwuDpLBvGXvEHrrEyvk6mussBOkwPH3flGidtzjo8
F8aeIEGRH2iy0NrIV/ZG2md6yyjbDMa/v2+uwG5Ifi5JIVdDHljTDcb8AbhVJWWe
qvnauy5uriAyfi/8DVJJ8LSYWzNbbN9pmuEgOdfwS+bTiPVV2wHEaVFoLp1l3C1+
iaR3flU/bOuAQALpkJw32+MND6paLk8wUGVBecvEmM34s11gb9lPk+Othl3A3FOU
FluiLbeyzNtUCElDaPH/ekw1zj4diabuzojDTevTlHQPYJVPKOQbt9VMvC7S+MsT
+gMCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH
ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHi+OnGkmdqu3gEHBKSEWSC0
kinyMB8GA1UdIwQYMBaAFPa/N2AAzf/QrQ5qkSwpriQAM188MA0GCSqGSIb3DQEB
CwUAA4IBAQC3qp3+ur9SWFrVKaM5thlOKuv7Pnp38qFaEoBWmAw+5ng88svfKd6w
ZVcENxCegHUBhlJ3NcVdIbVViYa+GoLLKCukAy2CWPKmRAfrWu7B8L4EMAR35B81
K1B2y+RBgWarpEpNS3sGTAJa5Rf9jReDv8BubLIYB0nIHBovCvifmfy9up9Qmoab
8JILaUOn+X6Wgepsa9Q7SfHRBr3rXu0P45ZuXPQfk+bgPW2dx3pkAZEMjZKsoWNf
ue2GY9AaxCjyeJbYUZK4EqHk9ZndzTo78KE9DkIUmQSgdvmknb6PZFv7Y5GrI4AG
T9dJR4PayBw8GWljPmoKmRTcYo98dWZj
-----END CERTIFICATE-----
subject=/C=JP/ST=Tokyo/O=TakaraSign/CN=helloworld-python.default.mahotakara.online
issuer=/C=JP/ST=Tokyo/L=Nihombash/O=TakaraSign
---
No client certificate CA names sent
---
SSL handshake has read 1582 bytes and written 436 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: 6D66B7908AA0B11F73840F191871BD99CE55C74029C5D03EAEC072C71603DD63
    Session-ID-ctx: 
    Master-Key: FCC669C61F6967C0AE8BD5D2089FE9D0C9CFD01098D9A121E299C7F0E23756BCD9029FF97851D330A956FD92023EB468
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 3c 0a cd ca a1 ad 68 20-e6 72 11 9a ca d9 d7 9a   <.....h .r......
    0010 - f1 92 06 7d c6 da f9 0b-92 90 df 7f e5 35 d9 55   ...}.........5.U
    0020 - 10 80 a4 dc bf a1 4a 66-8a 41 97 66 13 69 29 df   ......Jf.A.f.i).
    0030 - b4 d7 28 a6 75 fb a3 67-64 31 33 a5 6a 53 df 8f   ..(.u..gd13.jS..
    0040 - 0a cb 0c 5b 0c 29 85 9f-c2 04 1f 2e aa 88 07 75   ...[.).........u
    0050 - 19 e7 10 43 f9 f6 be e9-a6 ce ba 29 e8 8d 97 6c   ...C.......)...l
    0060 - 91 12 a8 86 22 1f f8 34-e9 29 30 c4 38 9e c1 dd   ...."..4.)0.8...
    0070 - 9e a7 42 e2 4c 04 06 ab-78 06 5f f6 5b ed d2 f2   ..B.L...x._.[...
    0080 - b1 22 73 71 0b 7f 7d f4-93 54 d8 87 92 2d c6 83   ."sq..}..T...-..
    0090 - 8a dc c4 04 22 53 3f a1-d1 fe b8 3f 2b 06 da 93   ...."S?....?+...

    Start Time: 1546781741
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

以上

34
30
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
34
30