カテゴリー: OS

投稿日:

Active DirectoryサーバをLDAPサーバとして使っている場合、2026年10月のWindows Updateで接続できなくなる可能性

php2shellのパッチをダウンロードするためにONTAPのダウンロードページにアクセスしたら、phpに関する警告の他に、下記の警告も出ていた

AD-LDAP Authentication Errors After Microsoft October 2026 DC Patch Updates
Microsoft October 2026 domain controller (DCs) patches may affect AD-LDAP authentication requests from ONTAP to DCs resulting in protocol outrages or login disruptions. See SU628 for more details.

Active DirectoryサーバをLDAPサーバとして利用している場合、2026年10月のWindows Updateにより、平文のLDAPアクセスが禁止され、署名ありのLDAPアクセスもしくはLDAPSアクセスが必須となる、という話だった

具体的なWindows Server側のパッチ
　Windows Server 2025 KB5126646
　Windows Server 2022 KB5126655
　Windows Server 2019 KB5126651
　Windows Server 2016 KB5126868

基本的に、Windows Server側に適用されたセキュリティ強化設定を解除することはできない

Windows Server側のLDAP接続に関するドキュメント「Active Directory Domain ServicesのLDAPチャネルバインディング概要」と「Active Directory Domain Services における LDAP 署名の概要」

NetApp側のドキュメント「2026年10月 ドメイン コントローラ更新後のLDAP無効な認証情報 FAQ」(英語版)

まずはLDAPSでアクセスするための「Active Directory Domain Services で SSL 経由で LDAP の証明書を構成する」で、署名などで使用する証明書を用意する

この設定については過去に「Windows Server 2025で作ったActive Directory環境でldapsを使えるようにする」でRHEL からopensslコマンドとldapsearchコマンドを使って確認する方法と共に記載している

次に「Active Directory Domain Services のグループポリシーを使ってLDAP署名を設定する」でクライアントからのアクセス時にLDAP署名を強制する設定を行う、と

クライアントからアクセスする時に確認するべき点のメモ

アクセステスト内容署名不要のDC署名必須のDC
LDAP(389) + Simple bind成功失敗（Strong Auth Required / LDAPエラー8）
LDAP(389) + SASL（署名）成功成功
LDAPS(636）+ Simple bind証明書があれば成功証明書があれば成功

ldapsearch コマンドで挙動を確認する手法のメモ

① 署名必須かどうか（LDAP+Simple bind）

確認コマンド

ldapsearch -x -H ldap://dc01.example.local \
  -D "user@example.local" -W \
  -b "dc=example,dc=local" -s base "(objectClass=*)" dn

署名必須の場合、下記の様なエラー

ldap_bind: Strong(er) authentication required (8)
  additional info: 00002028: LdapErr: DSID-0C09xxxx, The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection

② LDAP+SASL（Kerberos）＋署名での接続

確認コマンド

kinit user@EXAMPLE.LOCAL
ldapsearch -Y GSSAPI -H ldap://dc01.example.local -b "dc=example,dc=local" -s base dn

# 署名なしを強制して失敗するか確認（失敗すれば署名必須）
ldapsearch -Y GSSAPI -O "minssf=0,maxssf=0" -H ldap://dc01.example.local -b "dc=example,dc=local" -s base dn

③ LDAPSでのテスト

確認コマンド

# 証明書・TLSバージョンの確認
openssl s_client -connect dc01.example.local:636 -showcerts </dev/null

# LDAPSでbind
LDAPTLS_CACERT=/path/to/ca.pem \
ldapsearch -x -H ldaps://dc01.example.local \
  -D "user@example.local" -W -b "dc=example,dc=local" -s base dn

# StartTLS（389）
ldapsearch -x -ZZ -H ldap://dc01.example.local -D "user@example.local" -W -b "dc=example,dc=local" -s base dn

自己署名環境の場合、「LDAPTLS_REQCERT=never」を設定することで証明書検証を省略できる

LDAPS上でGSSAPIを使う場合、ADはTLS上のsign/sealを拒否するため「-O maxssf=0」オプションの追加、もしくは ldap.conf に「SASL_SECPROPS maxssf=0」を設定する

Windows環境で確認するためのメモ

PowerShellの場合

Add-Type -AssemblyName System.DirectoryServices.Protocols
$cred = Get-Credential   # user@example.local

# 389 + Simple bind（署名必須なら例外）
$c = New-Object System.DirectoryServices.Protocols.LdapConnection("dc01.example.local:389")
$c.SessionOptions.ProtocolVersion = 3
$c.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
try { $c.Bind($cred.GetNetworkCredential()); "389 Simple bind: 成功（署名不要）" }
catch { "389 Simple bind: 失敗 -> $($_.Exception.InnerException.Message)" }

# 636 LDAPS
$s = New-Object System.DirectoryServices.Protocols.LdapConnection("dc01.example.local:636")
$s.SessionOptions.ProtocolVersion = 3
$s.SessionOptions.SecureSocketLayer = $true
$s.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
try { $s.Bind($cred.GetNetworkCredential()); "LDAPS: 成功" }
catch { "LDAPS: 失敗 -> $($_.Exception.InnerException.Message)" }

Test-NetConnection dc01 -Port 636 はTCP疎通しか見ないため、TLSが成立するかの確認には上記のbindテストを使う

また、クライアント側でレジストリが設定されているか確認

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LDAP -Name LDAPClientIntegrity
# 0=なし, 1=ネゴシエート(既定), 2=必須

Active Directoryサーバ側で確認する手法

レジストリ「HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters」を確認

LDAPServerIntegrity が「1」は署名無し、「2」は署名必須

LdapEnforceChannelBinding が「0」無効、「1」サポートしてるなら使う、「2」必須

GPOでの設定項目「ドメイン コントローラー: LDAP サーバー署名必須」

イベントログでの確認

Directory Serviceのイベントログに出てくるイベントID

2886/2887：署名なしbindの存在・件数の警告

2889：署名なしbindを行ったクライアントIPとアカウント（「16 LDAP Interface Events」の診断ログを2に設定して出力）

3039～3041：チャネルバインディング関連

投稿日:

Windows版Claude DesktopのcodeでUbuntuへのsshが失敗する

Windows環境にClaude Desktopをインストールして、codeにてubuntuサーバへのsshを設定してみたところ接続できなかった

pcuser@192.168.1.21に接続できませんでした
SSH 接続を確立できませんでした。ホストに到達可能であること、および SSH の設定が正しいことを確認してから、再試行してください。詳細なエラーは以下に表示されています。
Host denied (verification failed)

先にうちの事例での答えを書いておくと、原因は2つ

・WindowsのOpenSSHをインストールしていなかった
　→ インストールした

・環境変数HOMEが未設定だったこと
　→ 設定した

これで解決しました。

解決に至るまでの経緯として。以下にメモを残しておく

まずClaude Codeでのsshトラブルの際に、Claude code側のssh設定は以下で確認できる

Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ssh_configs.json"

設定ファイルをみてもまあわかることはないかな

実際のログを確認するには以下をPowerShellで実行して確認

Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ssh.log" -Tail 60

今回は下記の様になっていた。

2026-08-11 22:28:06 [info] [ClaudeSSHManager] Initialized with version 5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 22:28:08 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: warm_up)
2026-08-11 22:28:08 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:28:08 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:28:08 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:28:08 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:28:08 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:28:08 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:28:08 [error] [RemoteServerController] Connection failed (79ms, trigger: warm_up): Host denied (verification failed)
2026-08-11 22:28:11 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: send_message)
2026-08-11 22:28:11 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:28:11 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:28:11 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:28:11 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:28:11 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:28:11 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:28:11 [error] [RemoteServerController] Connection failed (46ms, trigger: send_message): Host denied (verification failed)
2026-08-11 22:28:19 [info] [RemoteServerController] Detaching (leaving daemon running)
2026-08-11 22:34:38 [info] [ClaudeSSHManager] Initialized with version 5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 22:34:40 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: warm_up)
2026-08-11 22:34:40 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 22:34:40 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 0)
2026-08-11 22:34:40 [warn] [SSH2Connection] Host 192.168.1.21:22 is not in known_hosts
2026-08-11 22:34:40 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 22:34:40 [warn] [SSH2Connection] Rejecting host key for 192.168.1.21:22 — host is not in known_hosts
2026-08-11 22:34:40 [error] [SSH2Connection] Connection error: Host denied (verification failed)
2026-08-11 22:34:40 [error] [RemoteServerController] Connection failed (109ms, trigger: warm_up): Host denied (verification failed)

注目すべき点は「identityFiles: 0」

ホームディレクトリにある.ssh\known_hosts には複数の定義があるのに、「0」と報告されている

何が問題かを確認するため、HOME関連の環境変数定義の状態を確認

"HOME       = $env:HOME"
"USERPROFILE= $env:USERPROFILE"
"HOMEDRIVE  = $env:HOMEDRIVE"
"HOMEPATH   = $env:HOMEPATH"

そうしたら、HOMEが設定されていないことが判明

PS C:\Users\OSAKANATARO> "HOME       = $env:HOME"
HOME       =
PS C:\Users\OSAKANATARO> "USERPROFILE= $env:USERPROFILE"
USERPROFILE= C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "HOMEDRIVE  = $env:HOMEDRIVE"
HOMEDRIVE  = C:
PS C:\Users\OSAKANATARO> "HOMEPATH   = $env:HOMEPATH"
HOMEPATH   = \Users\OSAKANATARO
PS C:\Users\OSAKANATARO> 


PS C:\Users\OSAKANATARO> [Environment]::SetEnvironmentVariable("HOME", $env:USERPROFILE, "User")

設定後、Windows再起動

PS C:\Users\OSAKANATARO> "HOME       = $env:HOME"
HOME       = C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "USERPROFILE= $env:USERPROFILE"
USERPROFILE= C:\Users\OSAKANATARO
PS C:\Users\OSAKANATARO> "HOMEDRIVE  = $env:HOMEDRIVE"
HOMEDRIVE  = C:
PS C:\Users\OSAKANATARO> "HOMEPATH   = $env:HOMEPATH"
HOMEPATH   = \Users\OSAKANATARO
PS C:\Users\OSAKANATARO>

しかし、結果は変わらず

Claude自身に思考させるとSysteminternalのプロセス モニターで確認しろとのこと

Procmon64.exe を管理者実行。

  1. Ctrl+L でフィルタを開く
  2. Path contains ssh → Add → OK
  3. Ctrl+X で既存イベントをクリア
  4. Claude Desktop で接続を試行
  5. Ctrl+E でキャプチャ停止

なんかssh.exe を捜索してるログがたくさん・・・

Windows提供のOpenSSHを入れろとのこと

「Get-WindowsCapability -Online -Name OpenSSH.Client*」を実行して確認。

PS C:\Users\OSAKANATARO> Get-WindowsCapability -Online -Name OpenSSH.Client*


Name         : OpenSSH.Client~~~~0.0.1.0
State        : NotPresent
DisplayName  : OpenSSH クライアント
Description  : OpenSSH ベースのセキュア シェル (SSH) クライアントで、セキュアなキー管理とリモート マシンへのアクセスを
               可能にします。
DownloadSize : 0
InstallSize  : 0



PS C:\Users\OSAKANATARO>

「NotPresent」とインストールされていないので「Add-WindowsCapability -Online -Name OpenSSH.Client」でインストールする

PS C:\Users\OSAKANATARO> Add-WindowsCapability -Online -Name OpenSSH.Client


Path          :
Online        : True
RestartNeeded : False



PS C:\Users\OSAKANATARO> Get-WindowsCapability -Online -Name OpenSSH.Client*


Name         : OpenSSH.Client~~~~0.0.1.0
State        : Installed
DisplayName  : OpenSSH クライアント
Description  : OpenSSH ベースのセキュア シェル (SSH) クライアントで、セキュアなキー管理とリモート マシンへのアクセスを
               可能にします。
DownloadSize : 0
InstallSize  : 7995927



PS C:\Users\OSAKANATARO>

で・・・再起動しないでClaude Codeの再チャレンジをしてみたところ、今度は成功しました

成功した時のsshログは以下

PS C:\Users\OSAKANATARO> Get-Content "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ssh.log" -Tail 30 -Encoding utf8
＜略＞
2026-08-11 23:20:24 [info] [RemoteServerController] Ensuring server is ready on pcuser@192.168.1.21 (trigger: send_message)
2026-08-11 23:20:24 [info] [BinaryDeployment] Setting up remote server on pcuser@192.168.1.21
2026-08-11 23:20:24 [info] [SSH2Connection] Resolved pcuser@192.168.1.21 -> pcuser@192.168.1.21:22 (identityFiles: 7)
2026-08-11 23:20:24 [info] [SSH2Connection] Connecting to pcuser@192.168.1.21:22 (agent: none, keys: 1[ssh-ed25519], proxy: false, keyboard: true)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending SERVICE_REQUEST (ssh-userauth)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received SERVICE_ACCEPT (ssh-userauth)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (none)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_FAILURE (publickey,password)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Client: none auth failed
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (publickey -- check)
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_PK_OK
2026-08-11 23:20:24 [info] [SSH2Connection] ssh2: Outbound: Sending USERAUTH_REQUEST (publickey)
2026-08-11 23:20:25 [info] [SSH2Connection] ssh2: Inbound: Received USERAUTH_SUCCESS
2026-08-11 23:20:25 [info] [SSH2Connection] Connected to pcuser@192.168.1.21:22
2026-08-11 23:20:25 [info] [BinaryDeployment] Remote: home=/home/pcuser, platform=linux-amd64, shell=posix, localVer=5db5e4a12f88487e47c2c48259b69a2d630bb3f7
2026-08-11 23:20:25 [info] [BinaryDeployment] Server binary up to date (5db5e4a12f88487e47c2c48259b69a2d630bb3f7), skipping upload
2026-08-11 23:20:25 [info] [BinaryDeployment] CLI v2.1.222 cached
2026-08-11 23:20:26 [info] [BinaryDeployment] Remote server started
2026-08-11 23:20:26 [info] [BinaryDeployment] Bridge channel opened
2026-08-11 23:20:26 [info] [RemoteServerController] server capabilities: version=5db5e4a12f88487e47c2c48259b69a2d630bb3f7, methods=19, features=[process.stdin.offset]
2026-08-11 23:20:26 [info] [RemoteServerController] Connected to remote server (1557ms, trigger: send_message, reused: false)
PS C:\Users\OSAKANATARO>

ちゃんと「identityFiles: 7」と.ssh\known_hosts に登録されているホストの数が認識されていました

投稿日:

Linux上でのSecure boot関連操作のメモ

Secure Bootに使われるUEFI内に保存されている証明書に関して、Secure Boot開始初期にMicrosoftが作成した証明書の有効期限が切れてしまう、という時期になった。

LinuxでもSecure Bootを有効にしていると関係する話である。

AlmaLinux「Microsoft 2011 Secure Boot certificates have expired — AlmaLinux users are covered!」
Debian「SecureBootCAChanges」
DELL 「セキュア ブート証明書を確認する方法」
VMware「[TAM Blog] セキュアブート証明書の有効期限切れに関する注意点と対応について」
Dynabook「Windows セキュアブート証明書の有効期限切れについて」

Secure Bootの状態確認

Secure Bootが有効な状態となっているかを「mokutil –sb-state」を実行して「enabled」となっているか、で確認します。

pcuser@ubuntu:~$ sudo mokutil --sb-state
SecureBoot enabled
pcuser@ubuntu:~$

Secure Bootを使えない環境の例

[pcuser@almalinux9 ~]$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode
[pcuser@almalinux9 ~]$

Secure Boot証明書 データベースの登録確認

Secure Bootの証明書データベースに登録されているものは「mokutil –db」で確認します。

pcuser@ubuntu:~$ sudo mokutil --db
[key 1]
SHA1 Fingerprint: 13:7e:57:1f:0b:81:8a:0f:5c:32:3d:a2:7f:4a:ec:cf:95:98:0c:96
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e9:d9:ff:69:e6:f3:e7:e4
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
        Validity
            Not Before: Oct 16 17:16:05 2008 GMT
            Not After : Dec 31 17:16:05 2019 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c5:65:a7:45:cf:67:7f:f3:15:2e:79:0e:7f:53:
                    bb:cc:76:27:96:b7:6a:fa:08:93:b2:ac:84:74:59:
                    dc:3f:17:57:6d:e5:05:4d:fe:e5:b9:bc:1d:0f:ab:
                    80:81:0b:a4:bf:fc:64:c8:fe:54:46:4b:5d:93:ff:
                    ef:30:88:bf:3c:6c:25:0a:ef:12:6f:46:b6:dc:2e:
                    e6:a3:da:71:f0:80:e5:a3:21:22:fa:48:35:8b:5f:
                    66:29:cf:b9:1b:73:a2:8a:fe:29:52:cd:a5:e1:d4:
                    d7:f6:f0:b6:17:84:19:43:8f:8c:96:3a:f4:4d:67:
                    4b:48:b4:31:13:9c:c6:4c:8f:e4:83:44:a2:50:0a:
                    a4:75:b3:9f:c9:b0:b9:0c:9f:eb:bc:c7:c7:8b:34:
                    2d:9a:25:e9:81:98:a2:3c:da:2a:a5:8f:d1:7f:f6:
                    e5:11:14:3f:06:89:14:1f:04:8a:1c:ed:05:7f:3d:
                    b9:e7:dd:11:84:05:b0:3b:90:b8:9f:d4:18:05:0c:
                    5e:54:51:b4:de:4e:a5:ad:04:f4:3b:8b:0b:85:46:
                    88:5d:a1:94:12:86:d4:f1:53:1c:ab:c9:e4:df:a2:
                    6d:af:e0:9c:95:3c:75:c6:21:18:79:f6:2c:b0:f6:
                    ba:dc:a8:b3:5d:b8:b4:7a:40:7f:e6:c4:02:b0:5a:
                    13:7f
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                4A:D8:BA:04:72:07:3D:28:12:77:06:DD:C6:CC:B9:05:04:41:BB:C7
            X509v3 Authority Key Identifier:
                keyid:4A:D8:BA:04:72:07:3D:28:12:77:06:DD:C6:CC:B9:05:04:41:BB:C7
                DirName:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.
                serial:E9:D9:FF:69:E6:F3:E7:E4
            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        70:ef:b4:2e:c4:c4:ae:66:d8:18:20:27:1c:0c:8d:0d:4f:9e:
        93:b3:e7:f4:e5:95:6f:6c:09:45:79:16:27:20:c3:9d:94:3f:
        b0:db:c0:e7:b7:45:92:a7:4b:49:a7:43:8b:94:0b:59:c7:de:
        18:65:31:84:75:53:c0:35:bc:16:0b:2b:93:9b:d5:fb:52:52:
        a0:59:08:3c:37:a4:f5:01:51:f8:3f:bd:62:7b:35:25:ec:c6:
        bb:b5:21:9d:a2:17:5d:80:8a:0d:fc:1b:4c:87:53:83:63:b4:
        0b:d5:49:93:0d:69:f6:72:33:ec:da:ee:c8:39:8d:ac:8f:6a:
        be:80:33:b8:e1:68:e3:44:0a:66:03:75:45:ca:ca:2a:e0:10:
        ee:52:06:45:32:ca:1b:67:b7:d0:24:bc:9b:be:a2:91:59:0c:
        0a:7e:34:2a:26:4f:a5:80:15:b9:d3:47:23:cd:0b:c3:4b:c9:
        94:f8:43:d1:6f:87:48:39:ba:de:ef:16:82:13:cb:4d:0a:3f:
        05:c1:a1:be:64:7f:b2:54:d4:73:96:7d:85:a6:7a:c5:ee:d3:
        51:4c:4e:3c:77:bc:df:40:1b:49:62:60:70:f8:08:0b:dd:32:
        28:eb:d1:5b:57:08:2e:00:a8:c0:5b:21:35:71:28:36:43:3a:
        97:e9:6c:a3

[key 2]
SHA1 Fingerprint: 73:8a:96:2b:d9:c8:1b:72:77:17:af:17:ee:09:3f:e9:b4:ba:ee:c0
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e3:4c:a7:5a:0a:61:58:53
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
        Validity
            Not Before: Oct 24 06:47:59 2017 GMT
            Not After : Oct 19 06:47:59 2037 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
＜略＞

ちょっと量が多くてわかりにくいです。

重要なのは名称と有効期限です。

「mokutil –db|grep -e ‘Subject:’ -e ‘Not After’」で確認出来ます。

pcuser@ubuntu:~$ sudo mokutil --db|grep -e 'Subject:' -e 'Not After'
            Not After : Dec 31 17:16:05 2019 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
            Not After : Oct 19 06:47:59 2037 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
            Not After : Oct 19 18:51:42 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
            Not After : Jun 13 19:08:29 2035 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
            Not After : Jun 13 19:31:47 2038 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
pcuser@ubuntu:~$

ESXi 8上の仮想マシンなので、VMwareの証明書が2個入っていて、1つは有効期限が切れていました。

Microsoftの証明書が2011年発行のが2つ、2023年発行のが2つあり、2011年の1つは有効期限切れでもう1つももうすぐですね。

Secure Boot キー登録鍵の状態確認

KEY(Key Exchange Key)というUEFIに新しくSecure Boot用の証明書を登録する時に必要なものです。

「mokutil –kek」で確認します


pcuser@ubuntu:~$ sudo mokutil --kek
[key 1]
SHA1 Fingerprint: 45:9a:b6:fb:5e:28:4d:27:2d:5e:3e:6a:bc:8e:d6:63:82:9d:63:2b
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:00:13:14:16:b8:61:6d:82:82:4b:00:00:00:00:00:13
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021
        Validity
            Not Before: Mar  2 20:21:35 2023 GMT
            Not After : Mar  2 20:31:35 2038 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e3:5e:88:8b:73:2c:c3:0a:c4:e9:f5:ce:81:2d:
                    f1:0f:f1:26:35:37:d1:49:53:71:b1:5b:93:52:af:
                    e1:15:df:de:8b:39:bd:af:4c:65:75:53:e5:da:0a:
                    32:98:2f:33:26:b6:2b:be:94:99:9f:ec:da:c2:8e:
                    05:34:92:13:0f:63:bf:74:a2:72:a8:29:7e:9f:32:
                    21:29:08:59:c4:77:c4:2a:92:4c:87:b6:03:37:eb:
                    9a:e2:c3:c9:b4:48:21:c3:61:94:ea:17:51:b1:e7:
                    14:e2:24:63:2e:d5:f2:c6:a5:f2:a2:5e:1f:69:c6:
                    51:0d:a7:29:fb:52:0a:9b:e3:88:e8:68:ff:bb:fa:
                    92:69:af:c4:16:ff:5d:e5:5f:e0:df:ec:66:55:0b:
                    61:c2:ac:3b:20:6e:df:b4:0d:eb:2b:c8:d0:c2:34:
                    4e:82:96:39:ee:f1:31:85:04:3d:ef:d6:76:fb:c3:
                    ca:c1:d5:8c:2f:0b:10:28:9b:48:9a:b0:10:14:a4:
                    d9:94:e5:68:5b:cd:6e:e7:7a:ec:bc:a0:49:b8:a9:
                    53:d8:4d:2f:b2:7b:c8:da:bc:b2:e7:fc:ab:70:10:
                    77:95:45:49:fd:ad:d2:3f:17:cb:66:9a:f2:7d:36:
                    dd:0a:2c:e2:c0:87:21:2d:93:db:08:96:d2:e8:5c:
                    54:e1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            1.3.6.1.4.1.311.21.1:
                ...
            X509v3 Subject Key Identifier:
                E0:AB:72:BC:96:3E:FF:B8:66:9B:7D:10:5A:43:3E:5C:42:54:87:5F
            1.3.6.1.4.1.311.20.2:
                .
.S.u.b.C.A
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier:
                84:44:86:06:00:98:3F:2C:AA:B3:C5:89:F3:AC:2E:C9:E6:9D:09:03
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Devices%20Root%20CA%202021.crl
            Authority Information Access:
                CA Issuers - URI:http://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Devices%20Root%20CA%202021.crt
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        85:02:06:12:fa:67:ae:4f:39:a9:b8:34:dc:5d:2a:78:19:7b:
        38:ee:9c:82:8f:1b:e2:3c:3d:32:0a:5e:bf:58:06:e7:6f:f8:
        8d:18:a8:1b:84:f5:9b:ca:ad:8b:08:44:0e:26:8d:2c:d8:5f:
        6e:23:25:07:fa:5b:4c:26:2e:76:31:43:2e:6e:e8:c8:31:c1:
        4a:d2:f2:02:b7:a6:f1:75:e4:96:ed:06:e2:ca:95:78:44:a8:
        33:76:d4:2b:4d:d7:bc:dc:87:3b:ab:4d:29:ad:96:89:b7:d5:
        c2:8f:ab:46:c3:5d:b3:fd:ed:a5:9e:f5:76:b7:2b:85:ff:98:
        a1:9f:6b:1c:9b:3e:f7:ee:0e:17:a3:fd:36:2f:e1:cd:28:98:
        1c:40:99:26:ca:03:8d:a6:35:ea:d2:0a:a7:8b:16:ae:21:01:
        00:1e:27:0f:b7:0e:b2:42:31:56:2e:e6:f8:8e:ea:0c:34:f0:
        4e:df:70:30:69:04:d1:cf:d3:9c:64:46:6f:cc:21:cd:cb:ef:
        05:32:bb:08:a6:d8:9f:45:38:5d:4e:d2:9c:92:89:e9:73:e4:
        7a:08:35:1e:4f:a6:c2:ba:6b:3e:b7:1f:54:34:49:fa:b4:7a:
        cb:da:a0:1f:59:81:2b:2a:f6:88:26:b0:fa:6c:f2:eb:c1:d8:
        ae:41:e1:6f:fc:bf:13:e8:6e:14:e7:e7:c7:03:8b:40:99:10:
        38:06:6d:70:bd:01:c8:de:8d:56:1d:38:0f:4f:23:a8:25:40:
        de:bb:28:2d:43:af:a4:bc:20:83:b5:06:f9:05:21:9f:3b:b9:
        79:0d:70:6b:53:c0:75:c2:1b:10:13:b3:e4:6f:09:a8:cf:d1:
        b7:0e:71:5c:b7:c9:8f:e5:1c:f0:13:55:d9:93:b9:ae:5d:3f:
        ca:0b:b0:59:6a:45:4a:c3:e1:e3:27:78:0d:16:81:fc:58:2d:
        b1:41:ba:18:0d:cf:f0:ef:ab:08:1e:4f:f8:fc:c6:fd:4b:dd:
        1d:ef:30:25:50:39:a3:df:fe:3f:b9:fa:eb:96:97:d0:cd:f9:
        04:26:fb:0d:48:19:08:d8:e1:93:c1:50:c7:6e:6d:d8:d0:6b:
        8e:95:72:64:50:c9:ed:55:89:6e:c1:4b:a2:06:d4:32:b5:a9:
        6d:65:01:7a:f1:52:57:18:05:30:5c:b8:28:66:11:b7:7a:f0:
        71:4e:86:61:60:7a:6d:56:c7:5b:09:3e:a2:ef:d4:0e:9e:92:
        d3:1f:99:f6:9d:b1:1d:78:78:6b:ff:e8:2a:04:af:78:67:3e:
        f0:2a:0b:a7:e0:5d:01:e9:87:99:35:30:90:ed:d7:45:6b:9c:
        cc:e6:a2:e4:e6:17:a7:dd

[key 2]
SHA1 Fingerprint: 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:0a:d1:88:00:00:00:00:00:03
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 24 20:41:29 2011 GMT
            Not After : Jun 24 20:51:29 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
        Subject Public Key Info:
＜略＞

これもまた量が多いですが、こちらも重要なのは「Subject:」と「Not After」です

pcuser@ubuntu:~$ sudo mokutil --kek|grep -e 'Subject:' -e 'Not After'
            Not After : Mar  2 20:31:35 2038 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
            Not After : Jun 24 20:51:29 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
pcuser@ubuntu:~$

Secure Boot証明書 失効データベースの登録確認

今回の事例ではあまり重要ではないですが、明示的にダメな証明書群を登録する失効データベースがあります。

こちらは「mokutil –dbx」で確認します

pcuser@ubuntu:~$ sudo mokutil --dbx
[key 1]
  [sha256]
  80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
  f52f83a3fa9cfbd6920f722824dbe4034534d25b8507246b3b957dac6e1bce7a
＜略＞
  13a1f37bedfb5417b6b737e2a3816c8fd587d74d836914b2b2edc9fd6ca30e58

[key 2]
SHA1 Fingerprint: 8d:a5:a1:98:f2:e8:b2:7d:0d:51:d0:b4:d7:34:21:52:5b:a8:df:5d
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2806418927 (0xa7468def)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Debian Secure Boot CA
        Validity
            Not Before: Aug 16 18:22:50 2016 GMT
            Not After : Aug 16 18:22:50 2026 GMT
        Subject: CN=Debian Secure Boot Signer
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d3:d1:83:90:0f:da:65:a2:2f:07:5a:60:95:eb:
                    f7:c7:86:7c:20:86:da:65:a3:a6:12:eb:5b:3b:ce:
                    c8:fb:3f:a1:72:4b:9e:df:50:c5:03:33:a4:0c:2b:
                    5f:d6:41:04:0d:b6:cf:95:48:ed:8a:b2:ad:d6:e5:
                    01:37:4e:60:cd:b2:4a:38:04:b3:44:80:94:af:9f:
                    6e:54:db:a8:1f:3c:b7:4b:30:de:21:81:6f:09:a3:
                    66:ba:6a:2b:96:d6:9a:61:77:0c:d4:ed:3c:d0:71:
                    bb:ad:8c:f0:22:5c:3e:25:cc:6d:22:2e:61:97:95:
                    af:9b:2e:4d:58:b6:7e:78:02:c3:0e:b9:fa:b2:5b:
                    27:de:7d:a2:be:0c:14:ac:73:ec:97:b0:15:5e:ed:
                    ed:e5:a5:75:3f:78:e0:71:ce:2f:ce:83:ed:53:31:
                    30:98:4e:e6:f9:01:a2:88:88:a6:23:08:7c:0d:b7:
                    54:3a:16:95:ed:5e:79:5e:90:4e:fe:cd:aa:de:82:
                    fc:f6:96:71:4e:49:49:b9:d3:e9:b0:ab:7f:d7:2a:
                    47:b7:53:30:27:7c:dc:66:98:09:6f:d1:7e:f5:7f:
                    3d:3e:d4:a2:6a:88:59:02:2f:2f:3d:c8:c6:28:de:
                    42:fe:d9:52:3d:24:c2:fc:40:98:11:f6:76:bf:8c:
                    bb:65
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type:
                Object Signing
            X509v3 Extended Key Usage:
                Microsoft Trust List Signing
            X509v3 Key Usage:
                Digital Signature
    Signature Algorithm: sha256WithRSAEncryption
＜略＞

なんですかね、Debianの証明書が失効で登録されていました

Linux OS上でのアップデート？

fwupdtoolコマンドでアップデートができるらしい？

「fwupdtool get-updates」でアップデートがあるか確認できるらしい

pcuser@ubuntu:~$ sudo fwupdtool get-updates
ロード中…                [************************************** ]
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Devices with no available firmware updates:
 ~ UEFI dbx
No updates available for remaining devices
pcuser@ubuntu:~$

「fwupdtool refresh」で情報更新

pcuser@ubuntu:~$ sudo fwupdtool refresh
ロード中…                [************************************** ]
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Metadata is up to date; use --force to refresh again.
pcuser@ubuntu:~$

VMware上の仮想マシンだとアップデートがないので、実行できないけど

「fwupdtool update」でアップデートできるらしい

投稿日:

openKylyn 3.0 Alpha 1をインストールしてみた

「中国OS「銀河麒麟」、Linuxデスクトップ上でAndroidアプリのネイティブ動作を実現させる」という記事で、銀河麒麟(Kylin OS)のことが紹介されていた

2023年5月に openKylin 0.9.5 をインストールしてみたことあったけど、どう変わったのかな？と確認してみることにした

まず、openKylinの公式ページから openKylin 3.0 Alpha1 のISOを入手

仮想環境上で起動

openKylin 3.0 (huanghe) huanghe は 黄河の意味
Linux kernelは 7.0.0-1-generic

aptのレポジトリはこんな感じ

独自のものしかない感じですね

デスクトップ上の「安装 openKylin」をクリックしてインストールを行う

言語選択

「日本語」はないので「English」を選択

どうやら同じネットワーク内にあるサーバからコピーしてインストールする、という「Install from ghost」という機能がある模様

おそらくopenKylinのアカウント登録が必要なようだけどあとで

インストール開始

インストール完了

再起動・・・

「Computer」をクリックするとこんな感じ

スタートメニュー的なものが出てこないのはEnglish非対応なのか？

デスクトップの右クリックメニューから「Open Directory in Terminal」を実行

インストールユーザは「oem」で、ホスト名は「oem-PC」だった

とりあえず「sudo apt update」を実行してみたら、署名の問題が・・・

とりあえずUbuntu18.04で信頼できないレポジトリを使う で行った「deb [ allow-insecure=yes trusted=yes ]」を追加する対処を行ってみる

/etc/apt/sources.list への編集をしていなかったので、再修正

変わらない？

メッセージにある「apt modernize-sources」を実行

aptレポジトリの書式が変わるコマンドでしたか

/etc/apt/sources.list.d/ にある ~.sources 内にある「Trusted: yes」を「Trusted: no」に書き換えて見るもエラー

このあと、いくつか実験をしてみたが、解決にはいたらず

また、中国語以外だとうまく動かないだけ？というのがあったので、再インストール

変化はありませんでした

terminalで調査していたところ、突然表示されました

アプリの登録がない？

設定から言語変更を行う

下段の「検討言語」には「日本語」があった

再起動するとデスクトップのアイテムが日本語に

GUIからもソフトウェア更新は失敗、と

投稿日:

Windows OS上でユーザ権限でファイルシステムをマウントできるようにするDokany

バックアップソフトのCommvaultの 取得したバックアップデータを実際にはリストアしないでユーザ側に直接ファイルシステムとしてアクセスできるようにする3DFSについてドキュメントを見ていたところ、下記の記述があった。

Windowsバックアップデータを、Windowsサーバ上でファイルシステムとして見れるようにする場合、Dokany というオープンソースのコールバックファイルシステムが必要だという。

dokany を調べると github にあった

https://github.com/dokan-dev/dokany

“Dokany is a fork of Dokan 0.6.0 with bug fixes, clean change history and updated to build with latest tools.“

dokan !? 「Opendedupという重複排除機能搭載のLinux/Windows向けファイルシステム」で使われていたやつだ

2021年にdokan公式Webが消滅したので、forkしたってことですね

https://dokan-dev.github.io/ を見ると、Dokan FUSEを利用して、いろんなものをファイルシステムとしてマウントできるようにするものが作られているようです