例として、VerisignからSSL証明書を1通購入するものとします。この証明書は、iPhoneがデフォルトで信頼する認証局から発行されているため、ウェブサーバーにインストールすれば正しいSSL証明書として認識されます。
次に、このSSL証明書を発行する際に生成した私有鍵を使って詐称用の証明書に署名します。このときに、詐称用の証明書には任意のSubject DNやSubjectAltName:DNS等を指定できます。例えば、www.microsoft.comで使用するSSL証明書も発行できます。ここまでは、別に難しいことではなく、OpenSSLを使えば誰でもできてしまいますし、特に不正な行動ではありません。
問題はiPhoneで詐称用の証明書の検証する際に発生します。本来ならば、信頼された認証局(上記ではVerisign)から発行されたSSL証明書のBasicConstraintsフィールドのSubject TypeにはEnd Entityが指定されているはずなので、このSSL証明書の私有鍵で署名した証明書のパス検証を行うと、詐称用の証明書は無効な(invalidな)証明書として取り扱われなくてはなりません。
今回の問題は、詐称用の証明書のパス検証の際に、SSL証明書(上記ではVerisignから発行されたも)のBasicConstrainsフィールドの値を正しく確認しないために、詐称用のSSL証明書が有効な認証局から発行されたとして扱われてしまいます。つまり、第三者が勝手に発行したSSL証明書が有効な証明書として判定されてしまうのです。
これは結構大きな穴だと思います。7/15にiOS 4.3.4が出て、すぐに今回のアップデートが出たことを考えると、Appleもこの問題の危険性を認識しているのでしょうね。