Authenticode 署名用に GlobalSign から購入したコード署名証明書があります (彼らはそれを呼んでいます)。ここで、Java アプレットに署名する必要があり、まもなく Adobe AIR モジュール (アプレット?) に署名する必要があります。問題は、技術的な観点から、Authenticode 証明書と Java または AIR 証明書が同じ CA (Comodo または GlobalSign など) によって発行されている場合、それらの間に違いはありますか? 交換可能な場合、異なる証明書を購入しても意味がありません。
証明書のキー使用法フィールドは同じでなければならない (コード署名) ことは理解していますが、それらの証明書では拡張コード使用法またはポリシーまたはその他の拡張機能が異なる可能性があります。1 つの CA によって発行された 2 つ以上のタイプのコード署名証明書をお持ちの方がこれを確認していただけると幸いです。
http://www.adobe.com/devnet/air/articles/signing_air_applications.htmlには、次のような明示的なステートメントがあります。
「開発者は、任意のCAが提供するクラス3の高保証証明書を使用して、AdobeAIRアプリケーションに署名できます。」
残念ながら、Javaに似たものは見つかりません。ただし、さまざまなプラットフォームの最小証明書要件に関係なく、既存の証明書プロバイダーに連絡して、これらのプラットフォームに提供される証明書間に意味のある違いがあるかどうかを確認することをお勧めします。
Verisign Webサイトの何とか何とかは、証明書が購入者に配信される形式が彼らの提供物の唯一の本当の違いであると示唆していますが、実際にはこれを直接述べていないので、誰が知っていますか...？
RFC 5280から収集したものから、主要な使用法の拡張機能は、証明書がコード署名に使用できるかどうかを判断することしかできません。RFCには、JavaコードまたはAIRなどに署名するかどうかを制約できるものは何もないようです。これは、1つのコード（または他の種類の非キーデータ）に署名できる場合は、任意のコードに署名できることを意味しているようです。
とはいえ、証明書にはCA固有の拡張機能が含まれている可能性があります。証明書を見ないと、制限があるかどうかを判断するのは困難です。
技術的な観点から、クライアント（つまり、アプレットについて話している場合はブラウザ）がCAを認識し、キーの使用法と証明書の種類（DIGITAL_SIGNATUREとOBJECT_SIGNING）の組み合わせに満足している限り、問題はありません。
コード署名証明書は、言及されているどのプラットフォームでも機能するようです。GlobalSign のサポートに違いについて尋ねたところ、応答はありませんでしたが、その後すぐに Web ページが変更され、すべてのプラットフォームに対して 1 つのコード署名証明書を購入することになりました。