GroupDocs.Signature 26.9 の 3 つの変更により、静かな問題が顕在化します。期限切れ証明書は署名せずに例外をスローし、PDF デジタル署名は SHA-1 ではなく SHA-256 をデフォルトとし、SignatureSettings.LogLevel が実際にフィルタリング機能を提供します。本稿では、長年稼働してきたパイプラインに対する各変更の意味と、旧動作が本当に必要なケースへの対処方法を解説します。
26.9 リリースはセキュリティに重点を置き、.NET 10 の追加、より厳格なデフォルト設定、ポスト量子署名サポートを提供します。
暗号化されたPDFは復号コピーを書き出すことなく署名できます：LoadOptions がその場で開き、SaveOptions が署名後の出力が元のパスワードを保持するか新しいパスワードにするかを決定します。本記事では、失敗する2つを含む4つのパスワードパスを比較し、なぜ失敗が例外タイプではなく RuntimeError として報告されるのかを説明します。
ノートパソコン上で動作する Python 署名スクリプトは、スリムコンテナ内で 2 回失敗します。1 回目は .NET バインディングに libssl や libicu がなく、2 回目はイメージにフォントがなく、GroupDocs.Signature が欠落したフォントファミリーを代替しないためです。このチュートリアルでは、両方のレイヤーとスクリプトをポータブルに保つ解決コードを構築します。
Node.js 用の GroupDocs.Signature はプロセス内で JVM を実行するため、コンテナ化するには署名が機能する前に JDK とフォントを用意する必要があります。本記事ではフォントファミリーを選択する3つの方法（ハードコード、ファイル名から検出、ライブラリをプローブ）を比較し、それらに合わせたコードのバインディング上の注意点を解説します。
GroupDocs.Signature は欠落したフォントを代替しません: イメージに存在しないファミリ名を指定すると、フォールバックせずにエラーが発生します。.NET ランタイムイメージにはフォントが一切含まれていないため、フォントレイヤーを追加するまでテキスト署名は失敗します。本記事ではフォントなしイメージと修正済みイメージを比較し、実行時にファミリを解決する方法を示します。
Java コンテナイメージは AWT 用に DejaVu をバンドルしていますが、英語テキストの署名には十分でも他の言語には不十分です。本稿では、その部分的なカバレッジが文書ワークフローに与えるコスト、GroupDocs.Signature が代替せずに失敗する理由、そしてフォント層と実行時ファミリー解決がインシデントをスタートアップチェックに変える方法を解説します。
Version 26.2 の .NET 用 GroupDocs.Signature は、重要な Azure Key Vault 修正を追加し、デフォルトの署名長さを拡大し、NuGet 経由で利用可能です。
25.12 リリースでは、ステガノグラフィベースの画像デジタル署名、LINQ のパフォーマンス向上、そして Linux プレビュー生成に関する重要な修正が追加されました。
PDF ドキュメントを安全かつコンプライアンスに沿って署名するため、.NET 用 GroupDocs.Signature と PKCS#11 ハードウェアトークン（USB ドングル、スマートカード、HSM）の統合方法を詳しく解説したガイドです。