5

顧客がアイコンを含む独自のプロビジョニングプロファイルをアップロードできるようにしたいので、顧客に自分のアプリのカスタムバージョンをその場で作成して、公開することができます。

ただし、プロビジョニングプロファイルの検証に少し問題があります。特に、DeveloperCertificateが実際に有効な証明書であるかどうかを確認したいと思います。プロファイルは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ApplicationIdentifierPrefix</key>
    <array>
        <string>ABCDEFGH</string>
    </array>
    <key>CreationDate</key>
    <date>2012-03-28T11:17:23Z</date>
    <key>DeveloperCertificates</key>
    <array>
        <data>
        MIIFajCCBFKgAwIBAgIIddUra9YprMQwDQYJKoZIhvcNAQEFBQAwgZYxCzAJ
        BgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBs
        ZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBw
        ...     
        </data>
    </array>
    ...
</dict>

そこで、証明書を抽出して、できればopensslコマンドを使用して確認したいと思います。これらの証明書に使用される暗号化とは何ですか？opensslを使用して証明書を確認するにはどうすればよいですか？これはpkcs12を使用していると思いますが、それを試みるとエラーが発生します。

$ openssl pkcs12 -noout -in testcertificate
140653159306912:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1319:
140653159306912:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:381:Type=PKCS12

誰かが私を正しい方向に向けることができますか？開発者証明書の有効性をなんとかして確認できることが不可欠です。

ありがとう

4

2 に答える 2

8

私はこれを調べてきましたが、デビッドが説明するほど難しいものである必要はないことがわかりました. 解決策は実際には非常に簡単です。

この証明書は、base64 でエンコードされた DER 証明書です。あなたがする必要があるのは次のとおりです。

  • XML から証明書を抽出する

  • 証明書を Base64 でデコードします。

    base64 -d 証明書 > certificate.crt

  • OpenSSL で証明書をテストします。

    openssl x509 -inform DER -in certificate.crt -noout -text

または、パイプすると次のようになります。

cat certificate | base64 -d - | openssl x509 -inform DER -noout -text

この-textオプションは、openssl にすべての詳細を提供させますが、必要に応じて指定することもできます。たとえば、証明書が実際のディストリビューション証明書であるかどうかのみに関心があると仮定すると、-subject代わりにオプションを使用してCN=フィールドを確認できます。

于 2012-07-23T12:44:55.077 に答える
-1

さて、良いニュースと悪いニュースがあります。Mac/iOS のセキュリティ専門家である友人がいて、この分野で多くの仕事をしています。彼は実際に非常に似たようなことをしなければなりませんでした。彼から得た情報は以下の通りです。ただし、悪いニュースは、コマンド ラインで実行する方法ではありません。以下の手法を使用して、Mac アプリをスピンする必要があります。

-- テクニック ---

その XML ファイル内の証明書は ... NSData オブジェクトに読み込まれます。ただし、通常は 3 つの証明書があります。少なくとも Apple が生成したプロファイルでは。もしそうならわかんない。

3 つの証明書がある場合、通常はそのうちの 1 つ (通常は最後の証明書) が「Apple Root CA」と呼ばれ、SHA1 値が 16 進数の「611E5B662C593A08FF58D14AE22452D198DF6C60」であることを確認するだけで十分です。そのために、openssl.h の SHA1 関数を使用します。

おそらくリーフ証明書である証明書が1つしかない場合。それが問題ないかどうかを確認するには、通常、検証のために完全な「信頼チェーン」が必要になるため、より複雑になります。

いずれにせよ、Security.framework にリンクし、SecCertificateCreateWithData() を NSData (適切にキャスト) で呼び出して、SecCertificateRef を取得する必要があります。

相対的なショートカットは、SecCertificateCopyValues() を呼び出して「Authority Key Identifier ( 2.5.29.35 )」フィールド (その辞書キーは kSecOIDAuthorityKeyIdentifier のようです) を取得し、このフィールドの値が 16 進数の「E7342A2E22DE39606BB494CE7783612F31A07C35」であるかどうかを確認することです。 Apple が発行したすべての証明書に当てはまります。SecCertificateCopyValues() からの戻り値は、ネストされた辞書の辞書であるため、これを見つけるにはドリルダウンする必要があります。

完全かつ完全な答えは、証明書の参照を SecTrustSettingsCopyTrustSettings() に渡し、kSecTrustSettingsDomainUser、kSecTrustSettingsDomainAdmin、kSecTrustSettingsDomainSystem の順に渡し、証明書が明示的に信頼されているかどうかを確認することです。中間証明書がマシンにインストールされていない限り、それがリーフ証明書である場合、おそらく失敗します。

于 2012-07-19T21:23:36.703 に答える