カテゴリー: ガジェット Page 5 of 85

Ubuntu 24.04にWordPressをインストール。

概要

CMSの代名詞、Wordpressをきちんとした手順で書いていなかったのでこの機会にメモを残します。

手順が比較的簡単なだけに狙われやすいのも納得。

なので、ここではインストールだけではなく、セキュリティ対策を含めて実施します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL
  • PHP 8.3

前提

  • Apacheの初期設定は完了しています。
  • mod_securityが稼働しています。
  • 適切に名前解決できることが条件です。(DNS設定済み)
  • 証明書は適切なものを準備済みです。

さっくりとした手順

  1. WordPress用のデータベースを作成します。
  2. WordPressのプログラムを配置します。
  3. WordPressをWebサービスで動かす設定を行います。
  4. WordPressをブラウザでインストールします。
  5. インストール後、一度、設定を解除します。

※Wordpressは非常に狙われやすいWebアプリです。そのため、安定稼働するまでは設定をするたびにWebサービスから切り離します。

DB作成

  • MySQLログイン
mysql -u root -p
  • DB作成
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

DB名(mt)は自分の環境に合わせます。

  • ユーザー作成
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'your_password';

ユーザー(wpuser)やパスワードは自分の環境に合わせます。適正なパスワードを設定してください。

  • 権限委譲
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
  • 設定反映、MySQLログアウト
FLUSH PRIVILEGES;
exit

作成したDB確認

  • MovableTypeのユーザーでログイン
mysql -u wpuser -p
  • DB確認
SHOW DATABASES;

WordPressのDBがあることを確認します。

  • DB切り替え
use wordpress;
  • DBの文字コード確認
SHOW VARIABLES LIKE 'character_set_database';

Valueutf8mb4であることを確認

  • DBの照合順序確認
SHOW VARIABLES LIKE 'collation_database';

Valueutf8mb4_binであることを確認

exit

WordPress取得

  • 作業ディレクトリに移動
cd /hoge && pwd

任意のディレクトリを指定します。

  • wget
wget https://wordpress.org/latest.tar.gz
  • ファイルの解凍
tar -xzvf latest.tar.gz
  • ファイルの所有権変更
sudo chown -R www-data:www-data wordpress
  • www-dataディレクトリに移動
sudo mv wordpress /home/www-data/wordpress

自分の環境に合わせます。

WordPressWebサイト設定編集

ログ格納用のディレクトリ作成

  • ログ格納ディレクトリ作成
sudo mkdir -p /var/log/wordpress
  • ログ格納ディレクトリの所有者変更
sudo chown www-data:www-data /var/log/wordpress

WordPressのバーチャルサイト作成

  • /etc/apache2/site-available配下に、wordpress.confを管理者権限で作成し、以下のように編集していきます。
<VirtualHost *:80>
    # ドメイン名を指定します
    servername hoge.example.com
    # HTTPアクセスを強制的にHTTPSにリダイレクトします
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
    # ドメイン名を指定します
    ServerName hoge.example.com
    CustomLog /var/log/wordpress/wp_access.log combined
    ErrorLog /var/log/wordpress/wp_error.log


    # WordPressを配置したディレクトリを指定します。
    DocumentRoot /home/www-data/wordpress
    <Directory /home/www-data/wordpress>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    #セキュリティヘッダー付与

    Header always set Strict-Transport-Security "max-age=63072000"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"


#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile /path/to/ssl/certificate.crt
    SSLCertificateKeyFile /path/to/ssl/private.key
   # 証明書と秘密鍵のパスを指定します

    # Mod_Security設定
    SecRuleEngine DetectionOnly
    # Webでインストールを行うため、最初は検知モードに設定します。
    ## ファイルのアップロードをできるようにします。
    SecRequestBodyInMemoryLimit 524288000
    SecRequestBodyLimit 524288000

    ## テスト用の検知パラメーター
    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"


</VirtualHost>

# これらのセクションはSSL暗号化強度を高めるための記述です
# </VirtualHost>の外側に書くことにご注意ください

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC6-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

設定ファイル有効化

  • コンフィグ読み込み
sudo a2ensite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

ブラウザから確認

ブラウザで設定したURLにログインします。

インストール画面が出てきます。言語を選びContinueをクリックします。

ボタンをクリックします。

設定したDB名、ユーザー、パスワードを入力します。

DBと接続されると、以下が表示されます。インストール実行をクリックします。

サイト名などを入れていきます。

ここまで出たらOKです。

インストール後の処理(一時停止)

圧倒的なシェアを誇るWordpressは攻撃者が真っ先に狙うサービスです。
そのため、安定稼働するまでは確認後に一度停止して、物理的なアクセスを防ぎます。

  • バーチャルサイトの設定ファイル無効化
sudo a2dissite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

無効化後、上記の設定ファイルで指定したURLにアクセスできないことを確認します。

Redmine、ヘッダーに別サイトへのリンクを追加。(redmine_view_customize)

ヘッダーに別のサイトのリンクがほしいときは割とあるので、そのメモです。

動作環境

  • Redmine 4.2 /5.0/5.1
  • view_customize_pluginがインストール済み

コード

「新しい表示のカスタマイズ」で

  • パスのパターン:空白
  • プロジェクトのパターン:空白
  • 挿入位置:ヘッダー
  • 種別:JavaScript

で、以下のように入力。

$(document).ready(function(){
  // メニューの準備
  const menus = `
<li><a href="https://manualmaton.com" rel="noopener noreferrer">WordPress(manualmaton.com)</a></li>
<li><a href="http://barrel.reisalin.com" target="_blank" rel="noopener noreferrer">BookStack(Barrel Gazer)</a></li>
`;
  // 追加する
  $('#top-menu>ul').append(menus);
});

こうすることで、Redmineのヘッダーに

このようにリンクが追加されます。

思わぬ作業影響。

WebARENAにて新たなWebサービスを立ち上げようと思ったものの大失敗。

ちょっとハマってしまったので切り戻し。

しかし、同一サーバで稼働させているNextcloud上で、この謎の状況が起きました。

ロケールを en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 に設定できませんでした
これらのロケールのうちいずれかをシステムにインストールし、Webサーバーを再起動してください。

localectl 

を実行しても

System Locale: LANG=ja_JP.UTF-8
               LANGUAGE=ja_JP:ja
    VC Keymap: (unset)          
   X11 Layout: us
    X11 Model: pc105

と、正常な状況です。

何が起きたか?

新たに

  • perl
  • CGI

などを動かそうとパッケージをうにゃうにゃしていたときにこれが起きてしまったようです。

復旧

「転ばぬ先の杖」が功を奏しました。作業前にとっておいたスナップショットにより、作業前の状況に切り戻し。さながら「逆転時計(タイムターナー)」を起動させた気分です。

  • DB
  • データ

はバックアップを取ることで復旧できますが、新たなパッケージを動かしたときのようにシステム深奥まで影響を及ぼすような作業は全体のバックアップを取ることを学んで助かったという心境です。

ログ調査時にIPやステータスコードを抜き出すコマンド。

Apacheのアクセスログを調査するとき何かと使うのでメモです。

アクセスログからIPのみを抽出してカウント

 awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "/var/log/apache/access.log" | sort -u 

表示例

3 xxx.xxx.xxx.xxx
2 yyy.yyy.yyy.yyy
1 zzz.zzz.zzz.zzz

と、煩雑なその他のログを探すことなく件数とIPをカウントします。

更にステータスコードも表示

awk 'match($0, /[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { ip = substr($0, RSTART, RLENGTH) } match($0, /" [0-9]{3} /) { status = substr($0, RSTART+2, 3); print ip, status }' /var/log/apache/access.log | sort | uniq -c | sort -nr

表示例

5 xxx.xxx.xxx.xxx 200
3 yyy.yyy.yyy.yyy 404
2 zzz.zzz.zzz.zzz 500

ステータスコードが入るので、アクセス制御の有無やそれを突破してきたIPも調べられます。

Apacheにmod_dosdetector 導入

概要

過剰なWebクローラーによりサーバのパフォーマンスが落ちることがあるため、mod_dosdetectorを入れてみます。

mod_dosdetector は、Apache HTTP Server 用のモジュールで、DoS(Denial of Service)攻撃を検出し、対策を講じるためのものです。このモジュールは、特定のIPアドレスからの過剰なリクエストを監視し、しきい値を超えた場合にそのIPアドレスを一時的にブロックすることで、サーバーのリソースを保護します。

Ubuntu 20.04にはこちらを入れましたが、

  • ufwとの連携でサーバに負荷がかかる
  • 細かい設定が可能

ということで、こっちをUbuntu 24.04に入れてみます。

環境

  • Ubuntu 24.04
  • Apache 2.4
    • Apache2-devがインストールされていることが前提です。

さっくりとした手順

  1. gitでソースをダウンロードします。
  2. Makefileを書き換えた上でインストールします。
  3. 設定ファイルを作成します。
  4. 設定を有効化し、Apacheを再起動します。

mod_dosdetectorのダウンロード

  • ソース格納ディレクトリに移動
cd /usr/local/src && pwd

自分の環境に合わせます。

  • git clone
sudo git clone https://github.com/stanaka/mod_dosdetector.git
  • 展開したディレクトリに移動
cd mod_dosdetector && pwd

Makefileの書き換えとインストール

  • Makefile修正

デフォルトのMakefileは/usr/sbin/apxsとなっているため書き換えます。

sudo sed -i 's|^APXS=.*|APXS=/usr/bin/apxs|' Makefile
  • インストール
sudo make install
  • インストール確認
cat /etc/apache2/mods-available/dosdetector.load

LoadModule dosdetector_module /usr/lib/apache2/modules/mod_dosdetector.soと表示されます。

設定ファイル追加

参考: mod_dosdetectorを使ってみましょうよ。~挫折を乗り越え~

sudo tee /etc/apache2/mods-available/dosdetector.conf > /dev/null <<EOF
<IfModule dosdetector_module>
DoSDetection on
DoSPeriod 60
DoSThreshold 5
DoSHardThreshold 10
DoSBanPeriod 60
DoSTableSize 100
DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
</IfModule>
EOF
  • DoSDetection on
    • 説明: DoS (Denial of Service) 検出を有効にします。
  • DoSPeriod 60
    • 説明: DoS攻撃を検出するための監視期間を秒単位で指定します。
  • DoSThreshold 5
    • 説明: DoS攻撃と見なすリクエストの閾値を指定します。
  • DoSHardThreshold 10
    • 説明: より厳しい閾値を指定します。
    • 60秒間に同一IPアドレスから10回以上のリクエストがあった場合、即座にそのIPアドレスをブロックします。
  • DoSBanPeriod 60
    • 説明: DoS攻撃と見なされたIPアドレスをブロックする期間を秒単位で指定します。
  • DoSTableSize 100
    • 説明: DoS検出のために保持するIPアドレスの最大数を指定します。
  • DoSIgnoreContentType ^(image/|application/|text/javascript|text/css)
    • 説明: DoS検出から除外するコンテンツタイプを正規表現で指定します。

設定有効化とApache再起動

  • mod有効化
sudo a2enmod dosdetector
  • Webサービス再起動
sudo systemctl restart apache2.service

まずはこれで様子を見てみます。

設定ファイルの一括バックアップ時に用いるワンライナー。

概要

同一サーバに複数のバーチャルホストを運用している場合、個別のconfファイルの一括バックアップを取る必要があります。

その際、

sudo cp -pi /path/to/src/directory/*.conf /path/to/backup/directory/

としたのでは、オリジナルのファイルがファイル名そのままコピーされます。そういうときに、

  • 特定のファイルを一括でコピーしつつ
  • .bk.yyyy-mm-ddなどの識別子を付与

するTIPSです。

コマンド

for file in /path/to/src/directory/*.conf; do sudo cp "$file" "/path/to/backup/directory/$(basename "$file").bk.$(date +%Y%m%d)"; done

これで、コピー元にある.confファイル全てが、バックアップ先に元のファイル名に.conf.bk.yyyy-mm-ddが付与された状態で保存されます。

cdコマンドの後にpwdを付与する。

Linuxサーバで、どのディレクトリで作業をしたかは「どのコマンドを実行したか」と同等以上に重要です。

そのため、Linuxサーバでの作業において、どのディレクトリで作業をしているかを考えるため、

cd /hoge

を実行したら

pwd

が自動的に実行される設定を施します。

コマンド

  • 設定追加
sudo tee -a /etc/profile.d/pwd.sh > /dev/null << 'EOF'
cd() {
builtin cd "$@" && pwd
}
EOF
  • 設定反映
source /etc/profile.d/pwd.sh

これで、

cd /hoge

cd /hoge && pwd

と同じ結果を持つようになります。

Firefly-iiiのアップデート。(6.1.2→6.2.1)

LAMP環境で動く財務管理システム、firefly-iiiを6.1.2→6.2.1にアップグレードしたときの手順メモです。

参考:Upgrade a self-managed server/Firefly III documentation

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0.39
  • PHP 8.3.12
  • Composer 2.7.9
  • firefly-iii 6.1.2

さっくりとした手順

  1. DBのバックアップを取得します。
  2. 最新版のパッケージをダウンロードして展開します。
  3. 利用中のfirefly-iiiを待避させます。
  4. 待避させたfirefly-iiiからファイル/ディレクトリをコピーします。
  5. アップグレードを行います。

DBのバックアップ

  • 作業ディレクトリに移動
cd /hoge && pwd

任意の作業ディレクトリに移動します。

  • DBバックアップ
mysqldump --no-tablespaces --single-transaction -u username -h localhost -p database_name > DB_Backup.$(date +%Y%m%d).sql

usenamedatabase_name、及びDB_Backupは自分の環境に合わせます。

  • バックアップ確認
head -100 DB_Backup.$(date +%Y%m%d).sql

バックアップができていること、平文でSQLが読めることを確認します。

パッケージ取得

  • 作業ディレクトリに移動
cd /hoge && pwd

任意の作業ディレクトリに移動します。

  • wget
wget https://github.com/firefly-iii/firefly-iii/releases/download/v6.1.21/FireflyIII-v6.1.21.zip
  • ファイル所有者変更
sudo chown www-data:www-data FireflyIII-v6.1.21.zip
  • ファイル確認
ls -l FireflyIII-v6.1.21.zip

ファイルがあること、所有者がWebアプリ実行ユーザ(www-data)であることを確認します。

アップデート前のfirefly-iiiを待避

  • ディレクトリごと待避
sudo mv /home/www-data/firefly-iii /home/www-data/firefly-iii.$(date +%Y%m%d)

自分の環境に合わせます。firefly-iiiがインストールされているディレクトリをまるごと移動します。

  • 待避確認
ls -ld /home/www-data/firefly-iii

→ ディレクトリが無いこと

ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

→ ディレクトリがあること

アップデートパッケージの解凍と配置

  • 解凍
sudo -u www-data unzip -o /hoge/FireflyIII-v6.1.21.zip -x "storage/*" -d /home/www-data/firefly-iii

/hogeは先ほど取得したパッケージがある場所です。アップデート前と同じ位置、名前に解凍します。

  • 解凍・配置確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

アップデート前のファイル・ディレクトリをコピー

  • 待避させたディレクトリに移動
cd /home/www-data/firefly-iii.$(date +%Y%m%d) && pwd

自分の環境に合わせます。

  • .envファイルをコピー
sudo cp -pi .env /home/www-data/firefly-iii/.env

コピー先のディレクトリは自分の環境に合わせます。

  • .envファイルコピー確認
ls -l /home/www-data/firefly-iii/.env

ファイルがあることを確認します。

  • storageディレクトリのコピー
sudo cp -pir storage /home/www-data/firefly-iii/
  • storageディレクトリのコピー確認
ls -l /home/www-data/firefly-iii/storage

ファイルやディレクトリがあることを確認します。

アップグレード

  • アップグレード後のディレクトリに移動
cd /home/www-data/firefly-iii && pwd

先ほど展開したディレクトリに移動します。

  • DBマイグレーション
sudo -u www-data php artisan migrate --seed

Yesが見えるようにして実行します。

  • 一時複合化
sudo -u www-data php artisan firefly-iii:decrypt-all
  • アプリケーションキャッシュクリア
sudo -u www-data php artisan cache:clear
  • コンパイルされたビューのキャッシュクリア
sudo -u www-data php artisan view:clear
  • DBアップグレード
sudo -u www-data php artisan firefly-iii:upgrade-database
  • Laravel assportのキー生成
sudo -u www-data php artisan firefly-iii:laravel-passport-keys

アップグレード反映・確認

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service
  • アップデート確認
  1. アップデートを行ったfirefly-iiiサイトにブラウザでアクセスします。
  2. ログインできることを確認します。
  3. バージョンが上がっていることを確認します。
  4. 登録操作などができることを確認します。

アップデート後の処理:mysqldumpの削除

  • バックアップしたDBの削除
cd /hoge && pwd

mysqldumpを実行したディレクトリに移動します。

  • dump削除
rm DB_Backup.$(date +%Y%m%d).sql
  • バックアップ削除確認
head -100 DB_Backup.$(date +%Y%m%d).sql

ファイルが読めないことを確認します。

アップデート後の処理待避させたディレクトリの削除

  • 削除前:待避ディレクトリ確認
ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

ディレクトリがあることを確認します。(自分の環境に合わせます。)

  • 待避させたディレクトリの削除
[ -d "/home/www-data/firefly-iii.$(date +%Y%m%d)" ] && sudo rm -rf "/home/www-data/firefly-iii.$(date +%Y%m%d)"

それぞれ、待避させたディレクトリであることを入念に確認してから行ってください。

  • 削除前:待避ディレクトリ確認
ls -l /home/www-data/firefly-iii.$(date +%Y%m%d)

ディレクトリがないことを確認します。

Nextcloudのメンテナンス時に出てきたエラーに対処。

環境

  • Ubuntu 24.04
  • Nextcloud 29.8
  • PHP 8.3
  • MySQL 8.0.39
  • Apache 2.4

警告内容

Nextcloudのメンテナンスのため、以下のコマンドを実行。

sudo -u www-data php occ maintenance:repair

この警告が出たので対処をしていきます。

WARNING: Failed to create filecache trigger (compatibility mode will be used): Anng a query: SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege andmight* want to use the less safe log_bin_trust_function_creators variable)
WARNING: ffmpeg binary could not be configured

DBのトリガー修正

mysqlの設定ファイルのバックアップ

サーバの要となるサービスです。バックアップは確実に行ってください。

  • ファイルバックアップ
sudo cp -pi /etc/mysql/mysql.conf.d/mysqld.cnf /path/to/backup/directory/mysqld.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/mysqld.conf.$(date +%Y%m%d) /etc/mysql/mysql.conf.d/mysqld.cnf

エラーがなければバックアップは成功です。

設定ファイル書き換え

  • sedによるファイル書き換え
sudo sed -i '/\[mysqld\]/a log_bin_trust_function_creators = 1' /etc/mysql/mysql.conf.d/mysqld.cnf
  • 書き換え後の差分確認
diff -u /path/to/backup/directory/mysqld.conf.$(date +%Y%m%d) /etc/mysql/mysql.conf.d/mysqld.cnf
  • 差分
 [mysqld]
+log_bin_trust_function_creators = 1

設定反映

  • 反映前のサービス確認
systemctl status mysql.service

active(running)を格納します。

  • サービス再起動
sudo systemctl restart mysql.service
  • 反映後のサービス確認
systemctl status mysql.service

active(running)を格納します。

ffmgetのインストール

そもそもこのパッケージがインストールされていなかったので、

sudo aptitude install ffmpeg

として、パッケージをインストールします。

設定反映確認

  • Nextcloudのルートディレクトリに移動
cd /nextcloud/root/directory

自分の環境(/var/www/html/nextcloudなど)を指定します。

  • 設定確認
sudo -u www-data php occ maintenance:repair

冒頭のエラーがなければOKです。

証明書-中間証明書の整合性を確かめるワンライナー。

SSLサーバ証明書の発行/更新時のチェック方法のメモです。

今まではissuerとsubjectのハッシュ値が同じことを確認していましたが、より確実な方法を調べました。

前提

Let's Encryptのように、証明書と中間証明書が結合されている状態の証明書です。

コマンド

openssl crl2pkcs7 -nocrl -certfile /etc/certs/hoge.example.com.crt | openssl pkcs7 -print_certs -outform PEM | awk 'BEGIN {c=0;} /BEGIN CERTIFICATE/ {c++} { print > "cert" c ".pem"}' && openssl verify -CAfile cert2.pem cert1.pem

/etc/certs/hoge.example.com.crtは、サーバにある証明書をフルパスで指定します。

  1. 証明書をCRL(証明書失効リスト)を含めずにPKCS#7形式に変換。
  2. PKCS#7形式からPEM形式で出力。
  3. awkによって証明書と中間証明書に分解。
  4. サーバ証明書と中間証明書を分割。

を含めています。

実行結果

openssl verify -CAfile cert2.pem cert1.pem
cert1.pem: OK

と出れば、cert1.pem(サーバ証明書)がcert2.pem(中間証明書)によって正しく署名されていることを示しています。

主なエラーの意味と対策

unable to get local issuer certificate
  • 意味:中間証明書またはルート証明書が見つからないか、信頼されていない。
  • 対策:CAファイルに必要な中間証明書とルート証明書が含まれていることを確認します。
certificate signature failure
  • 意味:証明書の署名が無効であるか、改ざんされている可能性がある。
  • 対策:証明書が正しく署名されていることを確認し、証明書ファイルが改ざんされていないかチェックします。
unable to verify the first certificate
  • 意味:証明書チェーンの最初の証明書(通常はサーバ証明書)が検証できない。
  • 対策:CAファイルに正しい中間証明書とルート証明書が含まれていることを確認します。
self signed certificate in certificate chain
  • 意味:自己署名証明書が証明書チェーンに含まれている。
  • 対策:自己署名証明書が適切に信頼されているか確認します。

Page 5 of 85

Powered by WordPress & Theme by Anders Norén