このブログを検索

ラベル 証明書 の投稿を表示しています。 すべての投稿を表示
ラベル 証明書 の投稿を表示しています。 すべての投稿を表示

2026/03/13

自作メールサーバからiPhoneでメールが受信できない

dovecot+postfixのメールサーバが2台ある。

iPhoneでメールの送受信ができる。

dkimとかなんとかも設定している。

iPhoneが2台あるので、2台目でも受信できるようにしようとアカウントを設定した。

CA証明書もメールで送りインストールした。

しかし、2台目のiPhoneでだけ受信できない。


CA証明書が違うものか?と思って有効期限やシリアルを見て同じであることを確認した。

サーバで拒否している?fail2banで落としている?


が、firewall-cmdやfail2banで落としているかどうかもパッとわからない。

tcpdumpしてみる。

受信できる方は自宅のwifiにつなぎ、できないほうはwifiを切ってIPが変わるようにする。

それぞれのIPアドレスを確認し(いわゆる確認君の自作版で)、tcpdumpしてみると、

どちらからもサーバへのアクセスがある。

/var/log/maillog をtail -f で見る。

不正アクセスというか、ブルートフォースアタックというか、いたずらなのか、認証失敗アクセスが大量に来ている。

その中に自分のiPhoneのログもあった。

Mar 13 03:16:59 hogehoge dovecot[862]: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:0A000416:SSL routines::ssl/tls alert certificate unknown: SSL alert number 46 (no auth attempts in 0 secs): user=<>, rip=49.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS handshaking: SSL_accept() failed: error:0A000416:SSL routines::ssl/tls alert certificate unknown: SSL alert number 46, session=<cBUowtdMuuUxbXwH>


証明書がどうこう書いている。certificate unknown

証明書が不明、信頼できない、ということのようである。


証明書を見るのはクライアントである。クライアントがサーバの証明書を見る。それを信頼するためにサーバ証明書を発行(署名)したCA証明書をインストールしたのだ。

なのに、信頼できないと言っている。


copilotにこのログを投げつけ、いくつか情報を補足すると原因がわかった。

CA証明書はiPhoneにインストールしただけではだめで、

設定→一般→情報→証明書信頼設定 で、「ルート証明書を全面的に信頼」をオンにしなければならない。




2025/12/13

証明書更新2025

postfix/dovecotで同じものを使う。

いつもわからなくなるので拡張子として日付をつけることにした。


postfix

/etc/postfix/master.cf

smtpd_tls_cert_file = /etc/postfix/tls/postfix.pem.251213

smtpd_tls_key_file = /etc/postfix/tls/postfix.key


dovecot

/etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/postfix/tls/postfix.pem.251213

ssl_key = </etc/postfix/tls/postfix.key


openssl.cnにSANを設定し、CAでの署名時にextensionsを指定すること。

(以前、テキストにextensionsのみを書いて指定してできたのだがうまくいかなかった)

openssl ca -in ./postfix.csr -keyfile ./private/cakey.pem -cert ./cacert.pem -out ./jesus.postfix.pem -extfile /etc/pki/tls/openssl.cnf -extensions v3_req


2025/12/12

ASAいろいろ2025

Cisco ASAのssl-vpnをいろいろ直した。

今まではVPN接続後、ASAのLAN側(inside)のみアクセスしていたが、VPN経由でインターネット(outside)にアクセスできるようにした。そして、ASAのLAN側にいる端末は、ASAをGWとして普通にインターネットアクセスする。VPNクライアントはinsideにもアクセスできるようにする。

NATを以下のようにすればよい。

nat (outside,inside) source static VPN_POOL2 NAT_POOL2 destination static INSIDE_NW INSIDE_NW

nat (outside,outside) source dynamic VPN_POOL2 interface

nat (inside,outside) source dynamic any interface outside


1行目は、outside→inside、送信元:VPN、宛先:insideの場合。

送信元はinsideのサブネットに含まれるプールにNATし、宛先はそのまま。

2行目は、outside→outside、送信元:VPN、宛先any、outsideインターフェースにPAT

3行目は、inside→outside、ASAのLANからWANのPAT


1行目はVPNクライアントがinside に入るときにNATを除外する設定である。送信元をNAT_POOL2にNATしているが、これをしなくても、ASAのinsideには届く。ただし、その通信がVPNクライアントに戻るには、insideにある装置にvpnプールセグメント宛のルーティングが必要になる。それがいやだったのでNATしている。ただしNATするときにINSIDEのインターフェースアドレスにするとうまくいかない。

ASAの証明書の期限が切れていたのでついでに更新したが手こずった。 クライアント(iPhone)にCA証明書をインストールするにはCA証明書を.cerなどの拡張子にしてメールなどで添付すればよい。秘密鍵は不要。CA:TRUEのフラグがない証明書はiphoneでverifiedにならず、信頼する対象にならない。

CA:TRUEにするには、openssl.cnfに basicConstraints = CA:TRUE を設定すればよいが、その設定をしたセクションが反映するように明示していするなどしないといけない。

-extensions v3_ca を付けるとか。

署名したら証明書に CA:TRUEがついているか、確認する。(CSRではわからない)


# openssl req -new -x509 -days 3650 -key ./private/cakey.pem -out ca251212.crt -config /etc/pki/tls/openssl.cnf -extensions v3_ca

# openssl x509 -in ./ca251212.crt -text -noout | grep -A1 "Basic Constraints"

            X509v3 Basic Constraints: critical

                CA:TRUE


ASAの証明書は、ASDMでCSRを作成して発行された証明書をインストールする。デフォルトでCAフラグがオンになっているが、これはオンである必要はないがオンになっていたら機能しなこともないはず。


2024/11/07

postfix + dovecot (TLS有効)のメールクライアント設定

メールサーバのfqdnが mail.example.com
ユーザー名が taro
メールアドレスが taro@example.com
とする
サーバにtaroというユーザがあること
(Maildirが必要?調べればすぐわかるはず)

thunderbird

サーバ設定
 サーバの種類:IMAPメールサーバー
 サーバー名:mail.example.com
 ポート:993
 ユーザー名:taro

セキュリティ設定
 接続の保護:SSL/TLS
 認証方式:通常のパスワード認証
 送信(SMTP)サーバー
 サーバー名:mail.example.com
 ポート番号:465

セキュリティと認証
 接続の保護:SSL/TLS
 認証方式:通常のパスワード認証
 ユーザー名:taro
 
Thunderbirdの設定
 プライバシーとセキュリティ→証明書→証明書を管理→インポートをクリックして
 CA証明書をインポートする
 ※windowsにインストールしてもダメみたい


iPhone(英語)

Settings > Apps > Mail > Mail Accounts > Add Account > other > Add Mail Account 
 Name: (表示名)
 Email: taro@example.com
 Description: (説明)

INCOMING MAIL SERVER
 Host Name: mail.example.com
 User Name: taro
 Password: (パスワード)

OUTGOING MAIL SERVER > SMTP > mail.example.com
 PRIMARY SERVER: mail.example.com   が On
 > Server が有効
 Host Name: mail.example.com
 User Name: taro
 Password: (パスワード)
 Use SSLが有効
 Authentication: Password
 Server Port: 587

Advanced > INCOMING SETTINGS
 Use SSLが有効
 Authentication: Password
 IMAP Path Prefix /
 Server Port: 993

あれ、thunderbirdとiphoneでSMTPのポート番号が違うな?
どっちでもいいのか?

証明書について
postfixとdovecotでそれぞれサーバー証明書とサーバーの秘密鍵が必要。
同じものを使う。
サーバー証明書はCA証明書とチェーンになったものを使用する。
CA証明書はクライアントにインポートし、信頼する。


その他
以前、DKIMとかSPFを設定したが、とくになくてもgmailとかに送れる。
(gmailと自分のサーバしか試してないが)

dovecotでsslv3エラーが出るときの証明書

postfix & dovecotでSSL化していたメールサーバーの証明書の期限が切れていたため、更新したのだが下記のエラーが表示される。

2024-11-07T04:35:55.635061+09:00 jesus dovecot: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=xxx.xxx.xx.xxx, lip=xxx.xxx.xxx.xxx, TLS handshaking: SSL_accept() 


以前は送受信できていて変えたのは証明書だけだから証明書の問題かなと思い、何度も証明書を作り直したのだがなおらない。

ログをみると sslv3 と書いてあるが、sslv3はもう使用されない、使用すべきでない古いプロトコルである。

postfix&dovecot でプロトコルバージョンの設定をしたが変わらない。

ログの内容でググると、「証明書が中間証明書を含んだチェーンんになっていない」という情報が出てくるのだが、チェーン証明書など使わないでも以前は送受信できていたので関係ないと思っていた。

DovecotのSSLエラー - GentooやIoTの覚え書きブログ

しかしどうしてもなおらないので、下記を参考にチェーン証明書を作って置き換えてみたらうまくいった....

OpenSSLでチェーン証明書を作成する方法 #OpenSSL - Qiita

しかしなんでチェーン証明書でないとsslv3のエラーになるのか... 納得いかない...

チェーン証明書の作り方なんて知らなかったから、間違いなく以前は普通のサーバー証明書で動いていたはず。


ちなみに証明書はopensslを使って作った自己CA(?)で署名したヤツである。


2024/11/06

CA構築 2024

ubuntu 
サーバはj***、digital oceanのvps
Ubuntu

opensslのconfigは /etc/ssl/openssl.cnf

/etc/pki/CA に移動する。
ここで全部やる。

openssl.cnfを /etc/pki/CAにコピーする。

openssl.cnfを編集

[ CA_default ]
dir             = .            # Where everything is kept
private_key     = $dir/cakey.pem # The private key

[ req_distinguished_name ]
国とかcityとかのデフォルト値を入れておく


v3_ca
というファイルを作って下記を記載し、署名時に使う
(opnessl.cnfの[v3_ca]セクションに書いたら行けると思ったがだめだったので)
 
basicConstraints = critical, CA:true
keyUsage = critical, cRLSign, keyCertSign
subjectKeyIdentifier=hash


#これをやっておく

touch index.txt
echo 00 > serial

#ca証明書のcsr発行

 openssl req -new -key ./cakey.pem -out ./ca.csr

※openssl.cnfにkeyの場所を書いたつもりだが効かないので指定した
なぜ効かないとわかったかというとパスワードを聞かれたから


#CA証明書のCSRにサイン

openssl ca -in ca.csr -selfsign \
-notext -config openssl.cnf -outdir . \
-extfile v3_ca -out cacert.pem\
-startdate 241101000000Z -enddate 251031235959Z

いつもつけていなかったが、-notextを指定すると読める情報が書かれない(あっても問題ない)

-extfile v3_ca がさっきのCA情報

これもいつもやらないが、-startdate -enddateを明示的に指定。
指定しないと作った時間になって切りが悪いのでこっちの方がいい。

openssl x509 -in cacert.pem -text

中身を確認

 Version: 3 であること

下記があること

 X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

※この後別のcentos9のサーバでCA証明書を作ったが上記オプションがなくても問題なく使えた。

#iPhoneにCA証明書をインストール

証明書をテキストにコピーし、拡張子.crt (.pemでもいいはず)にして
メールでiPhoneに送る。

証明書をiPhoneにダウンロードして開き、インストールする。
(私はapple watchを使っているので、iphoneとapplewatchのどちらにインストールするかと聞かれた)

※私はiPhoneの言語を英語に設定している

すると、Settings > General > VPN & Device Management の、
DOWNLOADED PROFILE に表示されるのでタップして開くと、Not Verified と表示されている。
中身を見て、「Certificate Authority」がYesになっていること
Versionが3であること
を確認

最初に戻って、右上のInstallをタップ

ここで終わりではない。

General > About > Certificate Trust Settings > ENABLE FULL TRUST FOR ROOT CETIFICATES
で、インストールした証明書を信頼する。


2023/12/03

postfix/dovecot設定@centos9

昨日から今日にかけてpostfix/dovecotの設定をやった。

まずはubuntu 23.10(digital ocean)で、そしてcentos sgreanm release 9(さくらのVPS)で。

同じ設定をしたのだが設定個所や内容は微妙に異なる。osが違うというだけではなく、設定を紹介している人の理解とかやり方によるように見える。つまり、やり方は一つではない。

ubuntuでやった時はgmailのアカウントに送れなかったので、centosでやってみたのだが、こちらはspfもdkimも設定していないのに送れた。

ドメイン名は違っていて、centosでやった方のドメインは逆引きを設定している。逆引きがあれば(spfやdkimがなくても)、gmailに送れるのだろうか?


あと、iphoneの証明書の信頼は、ただCA証明書をインストールするだけではだめで、

Settings > General > About > Certificate Trust Settings 

で、ENABLE FULL TRUST FOR ROOT CERTIFICATESを有効にする必要がある。


証明書を作るとき、サーバの秘密鍵は暗号なしで作るのが楽。

いつもこういう風にしているが、

#openssl genrsa -aes256 -out ./server.key

Enter PEM pass phrase:


これでよい。

# openssl genrsa -out ./server.key


秘密鍵を暗号化して作った場合でも、以下のようにして解除できる(パスワードを入力する必要あり)。

# openssl rsa -in server.key -out server.key


また、暗号化した秘密鍵を使って、パスワードを設定する方法もある。

メールサーバを作ったがgmailに送れない(と思ったけど送れた)

※このエントリーを書いた後再確認したらgmailあてに送れるようになっていた。理由はよくわからない。備忘録のため残しておく


私はdigital oceanのVPSを使っていて、さくらインターネットで管理しているドメインの名前をつけている。そのサーバをメールサーバにしたのだが、色々やったあげくgmailアカウントにメールが送れなかった。

使ったのはpostfix/dovecotである。

postfixは送信(MTA)、dovecotは受信(MDA)でいいのだろうか?

何度か設定したが、いつもこの2つが不可分なような気がしてならない。


ただメールを送受信するだけなら簡単なのだが、まずSSL対応するのが面倒。

証明書が必要だったり、追加設定もたくさんある。設定ファイルも複数あるし。


いつもiPhoneをクライアント(MUA)として確認しているが、iphoneのメール設定もいつも忘れるのと、昔はメールと言えばSMTP/POPだったのに、いつの間にかIMAPが標準になって、でもiphoneの設定画面にはimapとpopが両方あって、どちらも使えるように見える。


あとサブミッションポートというものもよくわからない。25を587に変えるだけじゃないのか?

設定方法についてはいろんな人がブログなどで説明しているのでそれらを参考にすればできるのだが、バージョンやOSの違いなどで微妙な差がある。ブログとかだと記載ミスとかあるし、おそらく書き漏らしている手順とかもあるだろう。実際、書かれている通りにやってみてもうまくいかないことが何度もあった。


メールサーバなんか自分建てるものではない、と改めて思った。

とりあえずSSL対応してiPhoneで送受信できたのだが、gmailのアカウントに送ると、エラーになって帰ってくる。このことについても情報はたくさんあるのだが、「SPFまたはDKIMが必要」と言っている人が多いが、どうも両方必要なようである。さらに、逆引き設定も必要なようである。

SPFは簡単だがDKIMはめんどくさい。一体なんでこんなことをしなければならないのかと思いながらやっとの思いで設定を終えた。

しかしやはりgmailに送れない。ただし送れない理由がSPFとDKIMがなかった時と違っていて、「550-5.7.25 PTR record setup」がない、となっている。

逆引きが必要ならやればいいと思ってさくらインターネットのドメインコントロールパネルで追加しようとしたが、レコードの種類の選択に「PTR」がない。ドメインコントロールパネルは何度も使ったことがあるが逆引きを登録したことはそういえばなかったか。あったような気がするが、結論を言うとドメインコントロールパネルでは逆引き登録ができない。

ただし、さくらのVPSのホストの逆引き登録はサーバ自体の設定でできる。

しかし、今回私がメールサーバにしたのはdigital oceanのサーバで、そのアドレスの逆引き登録はできないのだ。

理由はよくわからないのだが、逆引き設定というのは間違いやすいとか間違うと重大な問題が起こるとかがあるのだろうか。

DNSサーバをdigital oceanのものにするとか、さくらのVPSのサーバをメールサーバにするとか、色々方法はあるだろうが、めんどくさいな....


2023/11/09

globalprotectのアンインストール

最近MacBookを使っている。別に必要だからではなく、せっかく二十数万円出して買ったのに使わないでいるのがもったいないからだ。

買った直後は興味もあったし勉強的な意味でもいろんなことをやってはみたが、何をやってもWindowsとの勝手の違いにイライラし、別にMacじゃないとできないことなどほとんどないし、と、いつの間にかほとんど使わなくなった。

とにかく画面はきれい。写真や動画がすごくきれいなのは気持ちいい。でも、それだけ。

同じ部屋でWindowsのノートPCと並べてWifiにつないで使っていたが、Macの方だけすぐ切れる。つなぎなおすとつながる。今まではそんなことはなかったが、引っ越したばかりの部屋で新しいWifiルータなので、それとの相性のようなものだろうか。

いろんなVPN設定がある。OpenVPN, Forticlient, globalprotect...

必要ないのでアンインストールしていったが、globalprotectはアンインストールできない。調べるとインストーラを起動してアンインストールを選択する必要があるらしい。インストーラが残っていないかと探したが残っていない。インストーラはpaloaltoに設定された「ポータル」にアクセスしてダウンロードする必要がある。ポータルへのアクセスは認証が必要である。インストールしてあるのだからポータルを設定して証明書も発行したのだが、まあまあ面倒くさかった覚えがある。またアクセスすればいいと思ったがpaloaltoの設定を見ると証明書の有効期限が失効している。

とりあえずポータルにアクセスできてglobalprotectのインストーラが落とせればいいのだが、認証が必要なので証明書の発行からやり直す必要がある... もうどこをやればいいのかわからないので、globalprotectの設定を全部やり直した。

paloaltoのバージョンもだいぶ上がっていたので最新にした。ただ最新にするには段階を踏む必要があり、アンチウィルスなどのパッチも必要なものが適用されている必要があるようでだいぶ時間がかかった。

証明書は今回のようなことがあると面倒だから有効期限10年とかで作ったらいざアクセスしたときにエラーになってしまう。作ってインストールすることはできるのだが、クライアントからアクセスするとエラーになり、強行もできない。それも、ブラウザとかOSとかによってできたりできなかったりする。

で、結局globalprotectでVPN接続して、消さずに残しておくことにした。


2022/02/06

CA作り直し

何度やっても忘れる...
#opensslの設定ファイル場所

/etc/pki/tls/openssl.cnf


#抜粋

####################################################################
[ ca ]
default_ca      = CA_default            # The default ca section

####################################################################
[ CA_default ]

dir             = /etc/pki/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.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several certs 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
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key


なるべくデフォルト値を使う
ファイル名は、キーは xxxkey.pem 証明書は xxxcert.pem とする。

コマンドは /etc/pki/CA で実行する。

CAの秘密鍵の場所は /etc/pki/CA/private.cakey.pem
CA証明書は /etc/pki/CA/cacert.pem



#CAの秘密鍵生成

[root@god tls]# openssl genrsa -aes256 -out ./private/cakey.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
..............+++++
..............+++++
e is 65537 (0x010001)
Enter pass phrase for ./private/cakey.pem:
Verifying - Enter pass phrase for ./private/cakey.pem:



#CA秘密鍵の場所

/etc/pki/CA/private/cakey.pem



#CAのcsr作成(openssl.cnfにデフォルト値を設定)

root@god tls]# openssl req -new 
-key ./private/cakey.pem 
-out ./cacert.csr

Enter pass phrase for ./private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Shinjuku]:
Organization Name (eg, company) [example]:
Organizational Unit Name (eg, section) [tech]:
Common Name (eg, your name or your server's hostname) []:myca.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:



#CAのcsrに自己署名してCAの証明書を生成(1行で入れる)

openssl x509 -days 365 -in ./cacert.csr 
-req -signkey ./private/cakey.pem 
-out ./cacert.pem

/etc/pki/CA/cacert.pem



#以下、サーバ証明書作成
#今回作成する証明書はpaloaltoのglobal protectで使う

#サーバの秘密鍵作成

[root@god tls]# openssl genrsa -aes256 -out ./gpkey.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.................................................................+++++
...................+++++
e is 65537 (0x010001)
Enter pass phrase for ./gpkey.pem:
Verifying - Enter pass phrase for ./gpkey.pem:


/etc/pki/CA/gpkey.pem



#サーバのCSR発行(1行で)

[root@god tls]# openssl req 
-new -key ./gpkey.pem 
-out ./gp.csr


Enter pass phrase for ./gpkey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Shinjuku]:
Organization Name (eg, company) [example]:
Organizational Unit Name (eg, section) [tech]:
Common Name (eg, your name or your server's hostname) []:hoge.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


/etc/pki/CA/gp.csr


#拡張属性指定

[root@god CA]# cat myext.txt
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
subjectAltName=DNS:hoge.example.com



global protectは下記の情報を参考に設定した。
paloaltoではCA証明書とサーバ証明書を発行できる。(自己署名)
しかし、その証明書を使うとiphone接続時に証明書のエラーになってしまう。
https://hirotanoblog.com/paloalto-globalprotect-local-db/4784/#toc1

iOSやmacosでは、拡張属性が設定されている必要があるらしい。
https://support.apple.com/en-in/HT210176

そのためにわざわざcentosのopensslで証明書を発行した。



CAサイン=証明書発行
#実際は1行で入力
[root@god CA]# openssl ca -in ./gp.csr 
-keyfile ./private/cakey.pem 
-cert ./cacert.pem 
-out ./gp.pem 
-extfile ./myext.txt


Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
ERROR:There is already a certificate for /C=JP/ST=Tokyo/O=example/OU=tech/CN=hoge.example.com
The matching entry has the following details
Type          :Valid
Expires on    :320203233742Z
Serial Number :06
File name     :unknown
Subject Name  :/C=JP/ST=Tokyo/O=example/OU=tech/CN=hoge.example.com
[root@god CA]#


#前回発行した証明書が有効なためerrorが出た。
#よくあるケースなのであえて残す
#この場合はrevokeする

[root@god CA]# ls ./newcerts/ -l
合計 32
-rw-r--r--. 1 root root 4002  6月  5  2021 01.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 02.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 03.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 04.pem
-rw-r--r--. 1 root root 4161  2月  6 08:31 05.pem
-rw-r--r--. 1 root root 5631  2月  6 08:37 06.pem
[root@god CA]# openssl ca -revoke ./newcerts/06.pem
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Revoking Certificate 06.
Data Base Update


#再署名

[root@god CA]# openssl ca -in ./gp.csr 
-keyfile ./private/cakey.pem -cert ./cacert.pem 
-out ./gp.pem 
-extfile ./myext.txt

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 7 (0x7)
        Validity
            Not Before: Feb  6 01:15:35 2022 GMT
            Not After : Feb  6 01:15:35 2023 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = example
            organizationalUnitName    = tech
            commonName                = hoge.example.com
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:hoge.example.com
Certificate is to be certified until Feb  6 01:15:35 2023 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated



#作った証明書の中身を確認


[root@god CA]# openssl x509 -in ./gp.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7 (0x7)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = JP, ST = Tokyo, L = Shinjuku, O = example, OU = tech, CN = myca.example.com
        Validity
            Not Before: Feb  6 01:15:35 2022 GMT
            Not After : Feb  6 01:15:35 2023 GMT
        Subject: C = JP, ST = Tokyo, O = example, OU = tech, CN = hoge.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b2:de:1f:bb:12:39:56:0f:4b:77:9c:5f:96:d2:
(略)
                    87:27:1a:0f:42:d8:f8:bd:b3:3c:25:dd:be:fa:92:
                    1f:bb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:hoge.example.com
    Signature Algorithm: sha256WithRSAEncryption
         66:76:ea:36:f8:9d:19:16:6f:3a:6c:1d:c1:b0:a8:f1:89:88:
(略)
         0b:74:e9:7e:f5:a1:ae:e1:a5:aa:b6:6b:62:7a:a8:14:7c:6a:
         b6:53:a5:d8
-----BEGIN CERTIFICATE-----
MIIDczCCAlugAwIBAgIBBzANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJKUDEO
(略)
dxQmAodMgTX6seEhz5DKzhUMG3Aie3pLVFnzuW27FPwTIxa2wt5lAvoBDGb5pWrb
tAt06X71oa7hpaq2a2J6qBR8arZTpdg=
-----END CERTIFICATE-----
[root@god CA]#


#証明書と秘密鍵を pfx形式にする

[root@god CA]# openssl pkcs12 -export 
-out ./gp.pfx 
-inkey ./gpkey.pem 
-in ./gp.pem

Enter pass phrase for ./gpkey.pem:
Enter Export Password:
Verifying - Enter Export Password:



pfxファイルをダウンロードする

tera termのSSH SCPが簡単

ファイルの属性を 666にしてから(最低必要な権限は何だろう?)

chmod 666 gp.pfx



#2023/11 追記
証明書をインポートするとき、CA証明書とサーバ証明書をインポートする。
CA証明書とサーバ証明書の組織は同じであること。
サーバ証明書は秘密鍵もインポートする。(インポート時に指定する)
CA証明書は「信頼されたルートCA」にする。

2021/06/06

postfixとdovecotの証明書更新

 先日適当にやってなんとか使えるようになっていたメールサーバの証明書が有効期限がすぎて、

iphoneでしつこく警告が表示されるようになったので証明書を更新したのだが、

その際にちょっと苦労したのでメモ。


まず、前提条件

・CAとメールサーバは同じサーバ。同じcn

・postfixとdovecotで使用する証明書は同じ


今回はcaの秘密鍵や証明書がどこにあるのが最新だかわからなくなってしまったので、

全部最初から作り直した。


やること。

1. caの秘密鍵生成

2. caの証明書作成(csrを発行して署名)

3. サーバの秘密鍵生成

4. サーバ証明書作成(csrを発行して署名)


postfixとdovecotの設定ファイルに証明書と秘密鍵の場所を設定する。


# grep smtpd_tls /etc/postfix/main.cf

smtpd_tls_cert_file = /etc/pki/tls/certs/server.crt

smtpd_tls_key_file = /etc/pki/tls/private/server.key


# grep tls /etc/dovecot/dovecot.conf

ssl_cert = </etc/pki/tls/certs/server.crt

ssl_key = </etc/pki/tls/private/server.key

ssl_ca = </etc/pki/tls/certs/ca.crt


# grep tls /etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/pki/tls/certs/server.crt

ssl_key = </etc/pki/tls/private/server.key


postfixやdovecotの設定パラメータやその書き方はよく変わる。

古い設定もしばらくは有効らしいがきっとそのうち使えなくなるので

なるべく最新にする。


ログを見ていると最新じゃないとかこの設定はいらないとか出ている。


サーバ秘密鍵は暗号化してしまうとダメときいたので暗号化しないようにした。





caで署名するときに秘密鍵や証明書を指定しないと設定ファイルの値を使うので、

設定ファイルを直すか、明示的に指定すること。

もしたまたま秘密鍵や証明書が存在していると、意図しないものを使ってしまうことになり、あとで正しい証明書として認識されないので注意。


わからなくなったら全部消してやり直すべし。


/var/log/maillog を見ていれば何が悪いかはだいたいわかる。



ca証明書をクライアントにインストールする。

私の場合iphoneでしか使わない。

iphoneの場合、pem形式のファイルをメールに添付して送ると開いたときにプロファイルとして保存されるので、それをインストールする。



2021/03/05

このアプリケーションのデジタル署名は、信頼できる認証局からの証明書を使用して生成されましたが、その認証局によって失効されていないことを確認できません。

 自前サーバの自前CAで署名した自前サーバ証明書をインストールした装置にアクセスしたときに、こんなメッセージが表示された。


「このアプリケーションのデジタル署名は、信頼できる認証局からの証明書を使用して生成されましたが、その認証局によって失効されていないことを確認できません。」


アクセス先装置の証明書を発行したCAの証明書は、アクセス元のPCにインストールしてある。

だから、「信頼できる認証局からの証明書を使用して生成されました」となっている。

だが、CRLを設定していない。


これはgmailのサーバ証明書だが、「CRL配布ポイント」というのがある。

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl.pki.goog/GTS1O1core.crl

という値が設定されている。

私が自前で発行したサーバー証明書にはこの項目がない。


そうか、CRL配布ポイントを証明書発行のときに設定してやればいいのか....

sanを設定したのと同様にテキスト(ext.txt)に書いて、署名時に -extfile ext.txt
を付けてやればよい。

crlDistributionPoints = URI:https://www.example.com/hoge.crl


これでCRL配布ポイントが証明書に入った。
サーバ証明書を入れ替えて再度アクセスしてみると、

今度は登録した CRL配布ポイントのアクセスが信頼できませんと言われてしまった。

ちょっと考えて、気づいた。

そもそもhttpsアクセスするための証明書なのに、それを検証するCRLの宛先もhttpsになっていたらそれも検証しなければならず、永遠に検証が終わらない。

というわけで、CRL配布ポイントのURLをhttpsでなくhttpにしたら、警告が消えた。

crlDistributionPoints = URI:http://www.example.com/hoge.crl


2020/10/11

ボクボク証明書(その1)

ボクボク証明書とは、自己署名証明書ではあるがオレオレ証明書よりはすこしマシな証明書のことである。

まず、証明書について基本的なことを確認しておく。

ここでいう証明書とは、インターネットのサーバにブラウザでアクセスするときにサーバが正統(正当?)であることを証明するための証明書のことである。

昔のインターネットでは、サーバ証明書などというものは必要なかったが、次第に利用されることが増え、最近では証明書を提示しないサーバとの通信は「安全でない通信」「保護されていない通信」などと表示されるようになった。

証明書を提示する通信は、「HTTPS」と呼ばれるプロトコルを使用する。

「HTTPS」とは、SecureなHTTPという意味である。

例えばオンラインショッピングでクレジットカード情報や住所等を入力するサイトである場合、そのサーバとの通信を他者に知られないように暗号化する必要がある。

HTTPSの通信が暗号化された通信であるという認識はほとんどの人が持っているだろうが、当たり前のことであるが、暗号化するには通信相手が本当に自分の通信したい相手なのかを確認する必要がある。

暗号化しているから安心だ、と、有名サイトを装った偽のサイト、いわゆるフィッシングサイトに接続してしまわないようにする必要である。

そのためにHTTPS通信ではサーバが証明書を提示し、クライアントはその証明書によりサーバがホンモノであることを確認して初めて「保護された通信」がおこなわれるのである。

しかし皆さんはおそらく『証明書がどうこうというのは知っているけど別にそれをいちいち確認してないけど』と思っているだろう。私もそうである。

サーバーがホンモノかどうか、つまり証明書が信頼できるかどうかは、ブラウザが判断している。

何をもって正統だと判断するか。

それは、証明書の発行者を見るのである。

そして、その発行者が信頼できる発行者であれば、その証明書は信頼できるとみなすのである。

ではどうやって発行者が信頼できるとみなすのか。

それは、「信頼できる証明書発行者リスト」というものを参照するのである。

それはあなたのパソコンの中にもある。


が、疑い深い人は、まだ安心できず「その『信頼できる証明書発行者リスト』が信頼できるとどうやって判断するのか、と思うだろう。


そしてここでようやくあなたの出番である。

あなたが使うパソコンにある、「信頼できる証明書発行者リスト」が信頼できるものであると、あなたが判断すれば、それを参照しているブラウザの判断も正しいとみなす。

あなたはそんなリストを登録した覚えはない、見たことすらない、というかもしれないが、

おそらくHTTPS通信というものはそういう建前で動いている。

自分で登録していなければ、ブラウザインストール時あるいはOSインストール時(インストール済みPCであれば購入時)に登録されるリストを信頼すると、あなたが受け入れていることになっているのだ。


前置きが長くなったが、ボクボク証明書を説明するために必要な前提条件である。

さて、「オレオレ証明書」とは、「発行者が自分自身である証明書」のことである。

今回発行する証明書も自分自身で署名しているのだが、一応「信頼」してもらえる証明書になる。

そのカラクリは、先ほど説明した「信頼できる証明書発行者リスト」にある。

もうお気づきであろう。

ボクボク証明書というのは、「信頼できる証明書発行者リスト」に、あなたという証明書発行者を追加してもらうことにより、信頼できる証明書としてもらうのである。


御託はこれくらいにして、以下、実践。

以前やった時とはいろいろ変わっていたので改めて手順を書く。


apacheとopensslのバージョンは以下


# httpd -v

Server version: Apache/2.4.37 (centos)

Server built:   Jun  8 2020 20:14:33


# openssl version

OpenSSL 1.1.1c FIPS  28 May 2019


手順の流れ

1.CA証明書作成

 1-1. CAの秘密鍵作成

 1-2. CA証明書のCSR発行

 1-3. CA証明書のCSRにCAの秘密鍵を用いて署名


2.WEBサーバの証明書作成

 2-1. WEBサーバの秘密鍵を作成

 2-2. WEBサーバ証明書のCSRを発行

 2-3. WEBサーバ証明書にCAの秘密鍵を用いて署名

 2-4. Apacheの設定ファイルで発行した証明書と秘密鍵の場所を指定


3. 動作確認

 3-1. CA証明書をクライアントにインストール

 3-2. サイトにアクセス


手順

以下手順では必要に応じてカレントディレクトリを移動しているので、ファイル名を指定する箇所のパス名は実施する状況に応じて変更が必要な場合があります。

ドメイン名、ホスト名等は必要に応じて変更しているので参考程度にしてください。


1.CA証明書作成

1.1 CAの秘密鍵作成

# openssl genrsa -aes256 -out ./cakey.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)

...................................................................................+++++

..........................................+++++

e is 65537 (0x010001)

Enter pass phrase for ./cakey.pem:(パスフレーズを入力)

Verifying - Enter pass phrase for ./cakey.pem:(パスフレーズを入力)


1.2 CA証明書のCSR発行

openssl req -new -key ./cakey.pem -out ./cacert.csr


※-keyでCAの秘密鍵ファイルを、-outで発行するCSRファイルを指定する。


# openssl req -new -key ./cakey.pem -out ./cacert.csr

Enter pass phrase for ./cakey.pem:(CAの秘密鍵のパスフレーズを入力)

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [XX]:JP

State or Province Name (full name) []:Tokyo

Locality Name (eg, city) [Default City]:Shinjuku

Organization Name (eg, company) [Default Company Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:ca.monqy.net

Email Address []:


Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

最後のチャレンジパスワードは書いてあるようにextraの設定なので入れなくてもよい。


1.2 CA証明書のCSRにCAの秘密鍵を用いて署名

# openssl x509 -days 825 -in ./cacert.csr -req -signkey ./cakey.pem -out ./cacert.pem

Signature ok

subject=C = JP, ST = Tokyo, L = Shinjuku, O = Default Company Ltd, CN = ca.monkey.net

Getting Private key

Enter pass phrase for ./cakey.pem:(CAの秘密鍵のパスフレーズ)


2.WEBサーバー証明書作成

以下が前提である。

opensslの設定ファイルの場所: /etc/pki/tls/openssl.cnf

openssl.cnfの設定

default_ca = CA_default
dir = /etc/pki/CA     

CAの秘密鍵の保存ディレクトリ: /etc/pki/CA/private/cakey.pem

WEBサーバ証明書等の保存ディレクトリ: /etc/pki/SSL


2.1 WEBサーバーの秘密鍵作成

# openssl genrsa -aes256 -out ./serverkey.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
............................................................................+++++
................+++++
e is 65537 (0x010001)
Enter pass phrase for ./server.key:(パスフレーズを入力)
Verifying - Enter pass phrase for ./server.key:(確認のためパスフレーズを再入力)


これはCAの秘密鍵を作ったときと全く同じことをしている。


2.2 WEBサーバーのCSR作成

[root@jesus SSL]# openssl req -new -key ./server.key -out ./server.csr

Enter pass phrase for ./server.key:(WEBサーバーの秘密鍵のパスフレーズ)

140637670844224:error:28078065:UI routines:UI_set_result_ex:result too small:crypto/ui/ui_lib.c:903:You must type in 4 to 1023 characters

Enter pass phrase for ./server.key:(WEBサーバーの秘密鍵のパスフレーズ)

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [XX]:JP

State or Province Name (full name) []:Tokyo

Locality Name (eg, city) [Default City]:Xxxxx

Organization Name (eg, company) [Default Company Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:*.monqy.net

Email Address []:


Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:


これもCAと同じことをしている。指定する秘密鍵がWEBサーバのものであることと、Common Nameが違うだけである。

Common Nameは *.monqy.net としているが、
こうしておくとホスト名が変わっても同じ証明書が使えるそうである。

たとえば、www.monqy.net でも www2.monqy.net でも、というように。


Common NameはCNと略され、サーバにアクセスするときのfqdnである必要がある。
fqdnとCNが異なっていると正しい証明書とみなされない。
さらに、今はCNがfqdnと一致しているだけでなく、もう一か所別の設定でもfqdnを記述する必要がある。
(後述)



---------------------------------------------
(追記)
openssl.confの設定により場所が異なるが、下記ファイルが必要

index.txt
serial.txt

今やったのだと /etc/pki/CA

index.txt はあれば中身がなくてもよいが
serial.txt は4桁の数字が書いてある必要があるらしい
今やったのは 0001 で成功した。
1  だけだと失敗する
-----------------------------------------

2.3 WEBサーバ証明書にCAの秘密鍵を用いて署名

以下のように書いたテキストを作る(san.txtとする)

subjectAltName=DNS:www.monqy.net

そして、署名の際に最後に以下のようなオプションを付けて署名する。
-extfile san.txt


openssl ca -config /etc/pki/tls/openssl.cnf -in /etc/pki/SSL/server.csr -keyfile /etc
/pki/CA/private/cakey.pem -cert /etc/pki/CA/cacert.pem -out server.crt -extfile san.txt
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 0 (0x0)
        Validity
            Not Before: Oct 11 01:25:48 2020 GMT
            Not After : Oct  9 01:25:48 2030 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = Default Company Ltd
            commonName                = *.monkey.net
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                31:D5:35:FC:B3:F9:6F:F0:29:84:47:4A:7C:B5:CB:8F:67:D0:26:2A
            X509v3 Authority Key Identifier:
                DirName:/C=JP/ST=Tokyo/O=Default Company Ltd/CN=*.monkey.net
                serial:5C:C5:FC:36:68:EF:F0:0A:CF:AF:DE:75:E5:1E:E6:4B:83:68:2C:38

Certificate is to be certified until Oct  9 01:25:48 2030 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

確認が2回来るのでyを入力する。
有効期間が10年間になっているが、デフォルトは1年である。

openssl.cnfの下記の設定で変更できる。
default_days   = 3650


-extfileで指定した「subjectAltName」であるが、最近はCNだけではなくこちらも見るようである。

これをやらないとchromeでは NET::ERR_CERT_COMMON_NAME_INVALID のエラーになる。

(参考)
https://www.pistolfly.com/weblog/2017/06/chrome%E3%81%A7-neterr_cert_common_name_invalid-%E3%82%A8%E3%83%A9%E3%83%BC.html

ここの記述によると、最近のchromeはcnは観ずにSANのみを見るらしい。


2-4. Apacheの設定ファイルで発行した証明書と秘密鍵の場所を指定

/etc/httpd/conf.d/ssl.conf


ServerName www.monqy.net:443

SSLProtocol all -SSLv3

SSLCertificateFile /etc/pki/SSL/server.crt

SSLCertificateKeyFile /etc/pki/SSL/server.key


ServerNameのfqdnがあっていることも確認

httpd再起動




3.動作確認

3.1 CA証明書のインストール

CA証明書をクライアント(Windows10)にダウンロードし、拡張子 .crt にして保存する。

/etc/pki/CA/cacert.pem
↓
ca.crt

ca.crtをダブルクリックすると証明書の内容が表示される。
「証明書のインストール」をクリックし、「ローカルコンピューター」「信頼されたルート証明機関」にインストールする。

※ここでなくてもよいかもしれないが、ここにインストールして確認した。

3.2 ブラウザでアクセス

Chrome, Edge, FireFoxでかくに...!!!

FireFoxでは信頼されない!!

「誰かがこのサイトに偽装しようとしている可能性があります。続行しないでください。
 
ウェブサイトは証明書で同一性を証明します。証明書の発行者が不明、証明書が自己署名、またはサーバーが正しい中間証明書を送信していないため、Firefox は www.monqy.net を信頼しません。
 
エラーコード: SEC_ERROR_UNKNOWN_ISSUER」



chromeとedgeで問題なかったので、念のためFireFoxでも見ておくかと思ったらこのザマだ。


エラーメッセージについて調べると、単にCA証明書が見つからないというだけのようだ。
FireFoxは例の「信頼されたルート証明機関」を見ていないのか?

「オプション」「プライバシーとセキュリティ」「証明書」「証明書を表示...」
「認証局証明書」に認証局証明書の一覧がある。

今回作成してインストールした証明書はない。
FireFoxは独自の場所に信頼するCA証明書のリストを持っているようだ。

ここに今回作成したCA証明書をインポートしてから接続すると、
ブラウザにエラーは表示されなくなった。

しかし、証明書を表示すると「Mozillaが承認していない発行者の証明書で検証された接続です」と表示される。

これも消したいな...




2019/07/27

公開鍵と秘密鍵のどちらで暗号化するのか

先日受けた安全確保支援士試験で公開鍵か秘密鍵かを選ぶ問題があった。

あまり自信がなかったので翌日WEBで検索していたら、自分の回答が間違っている、と愕然とした。

公開鍵暗号方式とは、暗号通信をおこなうときの受信者が、暗号化するデータを送信する相手に対し公開鍵を送付し、送信者はその公開鍵を用いてデータを暗号化して送信し、受信者は秘密鍵でそれを復号する方式である。

昨日の試験で、私は「秘密鍵は公開できないからそれで復号できない」と考えたことを覚えていたのだが、公開鍵で復号できるのなら暗号化の意味がないではないか!

しまった!

しかも、同じような問題が2回出ていて同じように考えた。

これを全部間違えていたとしたら、もうアウトだ。

というか、そもそもこんな単純なことを理解していないようではたとえ合格してもセキュリティの専門家を名乗ることはできない...

検索すると「秘密鍵で暗号化するという間違った解説が蔓延している」という記事がいくつも出てきた。

...が、さらによく調べると、「秘密鍵で暗号化(この言い方は微妙なのでカッコをつける)」する場合もあるらしかった。


そして、問題を見直してみると、

「xxxを用いて署名を作成」
「xxxを用いて署名を検証」

となっていた。

2か所ともに。


これは公開鍵暗号化ではなく、デジタル署名の話だ。
だから、署名を作成するのに用いるのは秘密鍵で、検証するのは公開鍵であっている。


でも私は、「公開鍵で復号(検証)できてしまったら意味がないのでは?」
という疑問を抱くこともなかったので、
たとえ合格していてもあまり胸をはって「俺は安全確保支援士だ」と言うことはできない。


デジタル署名において秘密鍵を用いて署名を作成することを、「秘密鍵で暗号化」というのは厳密には正しくないらしいが、
よくわからない。
私が信頼していてよく参考にしているWEBサイトでもそういう言い方がされている。

https://www.ipa.go.jp/security/pki/024.html

IPAのデジタル署名を説明したサイトにも、「生成したダイジェストを自分の秘密鍵で暗号化します。」という記述がある。



公開鍵、秘密鍵、証明書、署名...

これらについての説明は何度も何度も聞いた(読んだ)ことがある。
が、何度聞いても、当たり前すぎるような、なんとも腑に落ちない感じがあった。

暗号化というのは他人に内容を知られないように、何かを書き換えることである。
そして、当然、それは読むことを期待する相手には解読(復号)できなければならない。

私たちがよくやるのは、データを暗号化し、パスワードをかけることだ。
そして、そのパスワードを相手に伝える。

メールの添付ファイルをパスワード付きzipで圧縮して、
後からそのzipファイルの解凍パスワードを送信する、というのはよく見る光景である。
私もよくやる。

その際によく言われるのが、「ファイルを添付したメールにパスワードを記載するな」ということである。

それは宛先を誤った場合に他者にファイルを解凍されてしまうからだ。


この方式は、方式というほどのことではないくらいの簡単な方式だが、「共通鍵暗号」方式という。

私がそうなのだが、暗号化なんてこれしか方法がないんじゃないかと考える人が多いのではないだろうか。

しかし、これもすぐ気づくことであるが、共通鍵暗号方式では共通鍵を他者に知られないように、通信相手に渡す必要がある。


解読するための鍵をさらに暗号化しても、やっぱりそれを復号する鍵が必要になり、
何重に鍵をかけようと、この課題はついて回る。

その課題を解消するのが公開鍵暗号方式である。


公開鍵暗号方式では、暗号化する鍵と復号化する鍵をペアで用意する。

このとき重要なのは、二つの鍵はそれぞれ暗号専用、復号専用であるだけでなく、
当然かもしれないが、ペアになっている、ということである。

つまり、Aさんの公開鍵で暗号化したデータを、Bさんの秘密鍵では復号できない。

そしてもう一つ、復号化する鍵を他者に渡してならないことは誰にでもわかるだろう。

だがそれと同じくらい重要なのが、暗号化するために、データの送信者に対して、
受信者が公開鍵を渡さなければならないということである。

そして、そのためにさらに次の重要事項が発生する。
それは、公開鍵の内容は他者に知られてもかまわないが、
その公開鍵が暗号化したデータを送信したい相手の鍵であるかを確認しなければならない、
ということである。


物理的な鍵でたとえたいのだが、「開けるときと閉めるときで違うカギを使う」
という実例はないだろうか?

よく、南京錠の絵を使って、閉めることだけができる鍵、開けることだけができる鍵、
などと説明されるが、そんな物理的鍵はこの世に存在しない...

と思って検索してみたら、「投函できるが自分は鍵をもっていないポスト」と言っている人がいた。

なるほど、これに似ている。


誰でもポストに郵便物を投函できるが、ポストを開けることはできない。
しかし郵便物は相手に、相手だけに届かなければならない。

我々がポストに郵便物を投函するのは、それが郵便ポストであり、
それを開けて配達する郵便配達員を信頼しているからである。

公開鍵を送るというのは、ポストを設置するような行為だ。

我々はポストがポストであることを、真っ赤であるとか「ポスト」と書いてあるかとかいう程度でしか確かめないが、

電子的に暗号通信、つまり鍵(ポスト)と暗号文(郵便物)を交換する際には、第三者に証明するという方法を使っている。


その一つが、HTTPS通信で使用されるサーバ証明書である。

我々はサーバ証明書を見てそれが信頼できる発行者が発行したものであることを確認してアクセスする。
(実際にはブラウザが証明書の正当性を検証し我々はその結果を信頼している)

HTTPサイトにアクセスすると提示される証明書には公開鍵が含まれている。
アクセスする者は公開鍵を受け取り、それを使ってデータを暗号化して通信する。

そして、送信先のHTTPSサイトだけが、その暗号化したデータを復号できる。



2017/12/23

証明書が信頼されない2

http://monqy.blogspot.com/2017/12/blog-post_23.html
の続き

証明書内の cnを信頼せず、別のところを見ているらしい。
簡単に偽装できるからだろう。

以下をやってサーバ証明書への署名をすれば対応できると聞いて
やってみたが............

/etc/pki/tls/openssl.confを修正
[ req ]
req_extensions = v3_req

[ usr_cert ]
authorityKeyIdentifier=keyid,issuer:always

[ v3_req ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = *.example.com


今度は

NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

sha1になってる。


いろいろやったが、結局以下で。
vi ./openssl.cnf
#以下のセクションのパラメータを設定
[ CA_default ]
default_md = sha256

[ req ]
default_bits = 2048
default_md = sha256

[ usr_cert ]
basicConstraints=CA:TRUE
nsCertType = server

[ v3_ca ]
nsCertType = sslCA, emailCA

これをやって、CAを作り直す。

CAを作りなおす場合、
/etc/pki/CA/private/cakey.pem
があると
-newca
をやっても動かないので消す。

あと、いったんできたファイルは全部消しておく。

そんで、サーバの秘密鍵作成、CSR作成、署名をやりなおす。
apacheを再起動、CA証明書は、cacert.pemの最後の

-----BEGIN CERTIFICATE-----
から
-----END CERTIFICATE-----

までをテキストにコピーして拡張子 .crtにすればインポートできる。

chromeもいったん終了して再起動。


晴れてchromeに「保護された通信」と認めてもらえた。







証明書が信頼されない

(追記 証明書の有効期限は長すぎると信頼されなくなるようになっており10年とかにすると信頼されない)

自分のSSLサイトに証明書をつける。 金を出して買うのではない。 自己署名証明書でもない。 CAのお墨付きの証明書だ。 ただし、そのCAは自分で建てる。 結果的には自己署名証明書のようなものだが。 サーバはさくらのVPS、centos 6.9
# httpd -v
Server version: Apache/2.2.15 (Unix)
Server built:   Oct 19 2017 16:43:38
# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
下記三つのファイルに有効期限の設定があるが、
/etc/pki/tls/openssl.cnf
#365を3650に

/etc/pki/tls/misc/CA
#365を3650に

/etc/pki/tls/misc/CA
#1095を3650に

1. CAを作る

/etc/pki/tls/misc/CA -newca
CA certificate filename (or enter to create)

#enterを入力

writing new private key to '/etc/pki/CA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

#cakeyのパスワードを2回入力
#以下は適当に
#Common NameはURLとして入力するホスト名にする。

Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Tokyo
Locality Name (eg, city) [Default City]:Tokyo
Organization Name (eg, company) [Default Company Ltd]:example.com
Organizational Unit Name (eg, section) []:example
Common Name (eg, your name or your server's hostname) []:example.com
Email Address []:mail@example.com
以下は何も入力せずにenterでよい
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
CA証明書は下記にできる
/etc/pki/CA/cacert.pem
CA秘密鍵は
/etc/pki/CA/private/cakey.pam

2. サーバ証明書をつくる 

2-1. サーバ証明書の秘密鍵をつくる
# mkdir /etc/pki/ssl
# cd /etc/pki/ssl
# openssl genrsa -out server.key -aes256 2048
2-2. CSR(Certificate Signing Request)の作成
openssl req -new -key server.key -out server.csr

3. サーバ証明書に署名する

openssl ca -config /etc/pki/tls/openssl.cnf -in server.csr -keyfile /etc/pki/CA/private/cakey.pem -cert /etc/pki/CA/cacert.pem -out server.crt
パスワード、yを2回いれる。 下記のエラーになったときは、
failed to update database
TXT_DB error number 2
/etc/pki/CA/newcerts/に xxxxx.pem というファイルがあるはずなので、
openssl ca -revoke /etc/pki/CA/newcerts/xxxxx.pem
をやってから、署名をもう一度やる。
openssl rsa -in server.key -out server.key

4. apacheの設定

vi /etc/httpd/conf.d/ssl.conf
証明書と秘密鍵が /etc/pki/ssl にあるとして
SSLCertificateFile /etc/pki/ssl/server.crt
SSLCertificateKeyFile  /etc/pki/ssl/server.key
に変更して
service httpd restart
サイトにアクセスすると証明書が信頼できないというエラーが表示される。

証明書を表示すると「この証明書の発行者を検出できませんでした。」 となっている。

5. CA証明書をクライアントにインストール 

Windows10の場合 /etc/pki/CA/cacert.pem をクライアントにコピーし、拡張子を.crtに変える。
ダブルクリックすると証明書として表示されるので、「証明書のインストール」をクリックする。 ウィザードが走るのでインストールする。
私は「ローカルコンピューター」「信頼されたルート証明機関」にいれた。

さあこれでエラーが表示されなくなった.... と思ったら、ダメだ。
IEはエラーが表示されなくなったが、 chromeとfirefoxは依然として証明書を信頼してくれない。

chromeは
NET::ERR_CERT_COMMON_NAME_INVALID

Firefoxは
SEC_ERROR_UNKNOWN_ISSUER

....。

調べたら、対応策があるようなので、次回。

続き↓ https://monqy.blogspot.com/2017/12/blog-post_87.html