ここのデフよんブログのSSL証明書を、無料のLet’s Encryptで証明書一枚に自分で運用しているドメインとサブドメインをSAN（サブジェクトの代替名）で詰め込んで設定したのを数記事前に書きましたが、数日それで運用していたらGoogle Search Consoleから、ここのhttps://def-4.comのSSL/TLS証明書が自己署名されている証明書（通称：オレオレ証明書）だとメッセージを頂きました。
結論から言いますと、ドメインが違う場合は別々に証明書を発行したほうが良いであろうという内容です。以前の記事はコチラ。
このページの目次
届いたメッセージ
Google Search Consoleから届いたメッセージがコチラ
https://def-4.com/ の SSL/TLS 証明書が自己署名されています
https://def-4.com/のウェブマスター様
https://def-4.com/で使用されている SSL/TLS 証明書が自己署名証明書であることが判明しました。この証明書は認証局ではなくお客様のサーバーから発行されたものです。SSL/TLS 証明書の信頼できる発行元は認証局のみなので、この証明書はほとんどのブラウザで信頼されません。さらに自己署名証明書が使用されているサイトでは、コン テンツが認証されておらず、変更が可能で、そのサイトでのユーザーのデータや閲覧履歴が第三者に知られてしまう可能性があります。この結果、多くのウェブ ブラウザが、貴サイトにアクセスしたユーザーにセキュリティ警告メッセージを表示してユーザーをブロックすることになります。これは、安全でないサイト で、ユーザーの閲覧履歴が第三者に知られてしまうことを阻止するための措置です。
推奨される対処:
新しい証明書を取得する
この問題を修正するには、信頼できる認証局（CA）から専用の SSL/TLS 証明書を新たに取得します。この証明書はサイト全体の URL と一致させるか、ドメイン内の複数のサブドメインで使用できるワイルドカード証明書にする必要があります。
なぜ間違われたのか
自己署名証明書ということは、オレオレ証明書を使っているとGoogle先生に勘違いされているということで、早急になんとかしないと、これが原因で検索順位を落とされたりしたら一大事です。
Let’s Encrypt認証局から発行された証明書で、ブラウザーのアドレス欄の左に緑色の 鍵マークもしっかり出ているちゃんとした証明書なのにです。
ただし、あきらかに変則的な発行の仕方をしている点が一点だけあります。
別ドメインのSANに入れたのが原因?
家の自宅サーバーはapacheのバーチャルホスト機能でdef-4.comとikt-s.comの２つのドメインを運用させています。SSL証明書１枚で全部のドメインとサブドメインが対応できるなら、そのほうが楽そうだというたいした理由もなく、どちらかというとikt-s.comの方が私にとって重要なので、ikt-s.comをCN（コモンネーム）にして、その他サブドメインとdef-4.comをまとめてSAN（サブジェクト代替名）にして発行しました。これがダメだったようです。
せいぜいサブドメインまで
SANに別ドメインを入れても証明書は正しく発行できますが、Google先生が正しく認識してくれないなら合わせるしかありません。モヤっとしますが、長い物には巻かれよということです。
発行し直しました
ということで、def-4.comの証明書を発行し直しました。無料証明書ですから、気軽に発行し直せるのが良いですね。
一番最初に記入したドメイン名がCN（コモンネーム）になるようです。カンマかスペースで続けたのがSAN（サブジェクト代替名）です。ここの運用的にはdef-4.comをCN、www.def-4.comをSANにしたいところですが、従来一般のSSL証明書がwww付きの方をコモンネームにする（さすればwww無しが付いてくる）というのが一般的なので、使っていないwww.def-4.comの方をわざとCNにしています。あまり意味は無いかもしれません。
./certbot-auto certonly --apache -d www.def-4.com,def-4.com
そのうち対応するかも
Let’s Encrypt以前の証明書では、SANの方に別ドメインが入ってくるなんて事がなかったので、Google先生も勘違いしたのかとも思いますが、世界一優秀なGoogle先生ですから、すぐに対応してくると思われます。※あくまでもGoogleから今回のメッセージの原因がコレであるとの回答を得たわけではありません。明確な回答を得る手段もないので、あくまで原因も推測、対応も推測をもとに記事にしています。