"Lee Dilkie" writes: > Mine works fine. In a sense.
E = [EMAIL PROTECTED], E = [EMAIL PROTECTED], E = [EMAIL PROTECTED], CN = Thawte Freemail Member rfc 3280 http://www.ietf.org/rfc/rfc3280.txt p 23-24, section 4.1.2.6 Subject In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute.... Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. So this is not an rfc 3280 conforming cert, not even for legacy support. S/MIME v3 spec http://www.ietf.org/rfc/rfc2632.txt 3. Using Distinguished Names for Internet Mail End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification. The email address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name. Even the S/MIME v2 spec says that mail receiving agents (~clients) must recognize email addressES in both subject dn's and subject alt name fiels. ^^ So your cert may abruptly stop working or behave strangely in a client with fastidious rfc 3280 enforcement. One prominent vendor has been known to abruptly change its software to enforce aspects of rfc 3280. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
