Let’s Encrypt の証明書発行をDNS-01で行う場合の動作概要

Let’s Encryptの証明書発行操作について、これまではhttp/httpsを使う HTTP-01 を使っていたのだが、DNSを使う手段もある、というので確認してみた

example.comドメインで「mail.example.com」の証明書を発行する、とした場合、DNSに「_acme-challenge.mail.example.com」という名前でTXTレコードを追加して発行処理を行うようだ

全体の流れとしては下記の様な感じ

① アカウント登録(初回のみ)
② 当該サーバ → LEサーバ:「mail.example.com の証明書がほしい」(order)
 → LEサーバからdns-01 チャレンジ用のトークン を受け取る
③ 当該サーバ:DNSにTXTレコード登録
  トークンとアカウントキーから値を計算し、
  _acme-challenge.mail.example.com のTXT レコードに登録
→ セカンダリDNSにも反映されるまで待つ
④ 当該サーバ → LEサーバ:反映されたことを通知
⑤ LEサーバ → 権威DNS:
・_acme-challenge.mail.example.com の TXT を複数ネットワークのLEサーバから確認
・CAA レコードでLet’s Encrypt による証明書の発行が許可されているかを確認(CAAがなければ許可扱い)
  (mail.example.com → example.com の順で確認)
 → 検証OK
⑥ 当該サーバ:DNSに登録したレコード削除
   _acme-challenge.mail.example.comのTXTレコードを削除
⑦ 当該サーバ → LEサーバ: CSR を送信(finalize)
 → LEサーバ上から証明書をダウンロード

⑥⑦の実施順は逆の場合がある
認可が有効期間内の場合、②の段階で検証済みと応答されることで③~⑥のプロセスが省略されることがある

そう、確認において、mail.example.com のAレコード/AAAAレコードは確認されないし、Let’s Encryptサーバ側からのアクセスは行われないので、NATの内側にある内部向けのサーバであっても証明書発行が可能なようだ。

これは意外なことだった

問題点は、コマンドを使って _acme-challenge.mail.example.com のTXTレコードを登録/削除処理を行えるような DNSサーバなのか?ということ

certbotコマンドでは RFC 2136 Dynamic DNS Update を使うことが想定されている。その際の認証は TSIG (RFC 8945、Secret Key Transaction Authentication for DNS)を使用する。

各DNSシステムで実装の差異などがあるので「DNS providers who easily integrate with Let’s Encrypt DNS validation」を確認すると、certbot や acme.sh などで対応しているものを確認することができる

hp dragonfly G4についてのメモ

Googlebook OSで遊ぶためにhp dragonfly G4を入手しました

hpならパーツ単品でいろいろできるだろ、ということで中を開けてみる

WWAN用のスロットはあるけど、SIMスロットが見当たらない?

公式ドキュメントを確認してみるか、と 「HP Dragonfly 13.5 inch G4 Notebook PC Maintenance and Service Guide」を確認してみる。

・SIMスロットの実装有無でマザーボードを含む基盤系の差異はない、ように見える
・ケースについては、SIMスロット用の穴が開いてる/開いてないなどで差異がある

マザーボード上の実装としては、ネジを外して取り外さないとSIMスロットの有無がわからない場所の模様

続いて、タッチパネル対応の改造が可能かどうか

以前のhp機は、タッチパネル対応の有無でマザーボード側のコネクタピン数が異なっていた模様なのだが、dragonfly G3/G4ではタッチパネルの有無でマザーボード側に差異はない模様

ただし、OLED採用機については、マザーボードが別となる模様

タッチパネル改造をするのであれば、下記モジュールを入手する、と

明るい(1000nits) シルバー N51331-001 青 N51337-001
ほどほどアンチグレア(400nits) シルバー N51330-001 青 N51336-001
ほどほど(400nits) シルバーN51333-001 青N51339-001

バッテリーモジュールも2種類あることを確認
大容量6セル 68Whr M73476-006
標準サイズ4セル 45Whr M73478-006

ヒートシンク&ファンモジュールが2種類あるのは興味深い
標準 N11560-001
軽量 N11561-001 …軽量ってことはファンが普通よりよく回る、ということなんだろうか?

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:チャネルバインディング関連

4インチ前後で480×800の小型E-INK電子書籍端末群を比較する(Xteink X4 Pro,M5Stack PaperMono, reTerminal Sticky, Metalio E-INK4, Murphy M4)

4インチ前後で480×800解像度の小型E-INK端末がいろいろ出ている

aliexpressで見かけるやつでも探してみるとgithubで利用できるソースコードが公開されているものもあったりする

それらをまとめてみた

claude opus5に比較表作らせた時のお勧めについては下記

以下は検索用の文字表記版

製品名X4 ProX4 ClassicMurphy M4PaperMonoreTerminal StickyMetalio E-INK4
SoCESP32-S3ESP32-S3ESP32-S3ESP32-S3R8ESP32-S3R8ESP32-S3
PSRAM / Flash8 MB Octal / ? MBなし / 4 MB8 MB Quad / 16 MB8 MB Octal / 16 MB8 MB Octal / 32 MB??MB Octal / 16 MB
画面仕様4.3″ 480×800 219 ppi4.3″ 480×800 219 ppi4.26″ 480×800 219 ppi3.97″ 480×800 235 ppi3.97″ 800×480 235 ppi3.97″ 800×480 235 ppi
E-INK表示機構SSD1677SSD1677SSD1677SSD1677SSD1677SSD1677
タッチ○
GT911 (0x5D)
×○
FT6336U(0x2E)
○
FT6336G(0x38)
○
GT911(0x5D)
○
CST816S
物理ボタン計3個
電源
側面2
計7個
電源
側面2
前面2
上面1
計3個
決定&電源
UP
Down
計3個
電源
Up
Down
計3個
決定&電源
UP
Down
見た目的には計7個
内部的には3個+仮想ボタンらしい
フロントライト○ 2ch 暖/寒×○ 2ch 暖/寒○ 1ch 輝度のみ××
バッテリ1,100 mAh
CW2017
920 mAh
CW2017
容量非公開
ADC
1,150 mAh
ADC
750 mAh
BQ27220
容量非公開
BQ27220
RTCBM8563(0x51)なしなしRX8130(0x32)なしPCF8563
充電ポゴピン(USB-C コネクタなし)ポゴピン(USB-C コネクタなし)USB-CUSB-CUSB-CUSB-C
microSD○○○○○○
IMUなしQMI8658なしBMI2706軸IMUSC7A20H
音声なしなしスピーカーあり?PDM マイク+ブザーマイク+ブザースピーカー+マイク+BT
無線Wi-Fi/BTWi-Fi/BTWi-Fi/BTWi-Fi/BT, LoRaWi-Fi/BTWi-Fi + 外付BT
重量72g68g74.7g70g
その他吸着磁石吸着磁石側面3ボタンIMU, RTC, RGB LED温湿度, IMU, 磁石加速度, RTC, 振動, カメラ端子
CrossPoint公式公式PR crosspoint-reader/crosspoint-reader#2930 公式公式未対応
関連資料––機器資料
crosspointの移植github
公式資料公式資料
公式github
機器資料
読書最優先 Xteink X4 Pro2ch 寒暖照明
GT911 によるタッチ操作
バッテリー残量検出が正確
完成品としての仕上げが最も高い
microSDへのアクセスはSDMMC 1bitとそれなり
欠点はポゴピン充電で、汎用のUSB-C ケーブルが使えないこと
ボタン派・軽量 Xteink X4 Classic68 g / 4.9 mm
個別ボタン7個で全操作が完結
バッテリー残量検出が正確
QMI8658 使った物理的に振ってページ送り
初代X4より高速化
microSDへのアクセスはSDMMC 1bitとX4より早い
欠点は 照明とタッチがないこと
読書+工作 M5Stack PaperMono1ch 照明
タッチ対応
LoRa と NFC に対応したHW
microSDへのアクセスはSDMMC 4bitと高速
欠点は、開発キット寄りの筐体と次回生産時期が2027年予定
最安で弄る reTerminal Stickyセンサー類が搭載されていて、読書専用機というより貼れるサイネージ兼リーダーという作り
欠点は、ライトなし、とmicroSDアクセスがSPIと共有の為、遅いこと
2ch 照明+自前ビルド Murphy M42ch寒暖照明
microSDへのアクセスはSDMMC 4bitと高速
欠点は、crosspoint reader公式非対応と、バッテリー残量検出がADCによる電圧からの推測のみということ
AI 端末自作 Metalio E-INK4スピーカー・マイク・BT 音声・振動・RTC・カメラ端子を積んだ音声アシスタント基板。
microSDへのアクセスはSDMMC 1bitとそれなり
欠点は、現状crosspoint reader未対応、ライトなし、ということ

下記は製品写真

Androidにつないだ日本語配列Bluetoothキーボードで記号がちゃんと入力できない

だいぶ前に購入したBluetooth キーボード SK-9071 をAndroidタブレットで使ってみようとしたところ、キーボードが英語配列として認識されたようで、記号の入力がうまくいかない状態でした。

ぐぐると2022年の「Androidタブレットへの日本語配列キーボードの繋ぎ方」という記事があり、そこではGboardだとうまく動かないので、サポート終了してるGoogle日本語入力を使った、と書かれている。

いろいろ確認したところ、2026年時点ではGboardでもなんとかなることが確認出来た。

ただ、元凶はGboardがしっかりしてないから、ということには代わりは無かった

その現況のGboardから見えるBluetoothキーボードの配列に関する設定が下記の様に「日本語 109A 配列」となっていても、@ キーを押しても @が入力できないという状況の時に何をすればいいのか

それはBluetoothキーボードでCtrlキーとスペースキーを同時押しすること。

これにより、Androidシステムの言語切り替えの仕組みが動いて、日本語配列が認識されました。

ただ、よくわからないのは、これで英語配列→日本語配列になったということは、もう1回、Ctrl+Spaceを押すと日本語配列→英語配列になるのか?と思ったら、2回目以降はただの変換モードのオン/オフに変わりました。

察するに、「Gboard 英語配列」で動作していたものを設定上は「Gboard 日本語109A配列」に変更しても内部的にはまだ切り替わっていなくて、Ctrl+Spaceを押すことで「Gboard 日本語109A配列」設定に変わっていることが認識されたんじゃないか、ということですね