Re: Problems generating a CSR

[David Goldberg]

I agree that looking up the attribute NID seems unnecessary. My intial code called X509_NAME_add_entry_by_NID(), but since that wasn't working I decided to try an approach more similar to the O'Rielly example which does the NID lookup (which obviously didn't help).   Some additional info:   Verisign does not seem to require the NEW in the header. I tried a certificate request generated by openssl.exe, without the NEW in the header, and Verisign had no problems with it. (Obviously I am doing something a little different from openssl.exe, though I'm not sure what)   I talked to Verisign support, and they looked at the CSR and claimed it was missing the "Common Name" field. I see the CN entry when I dump out the CSR with openssl.exe, so I don't know if the guy is onto something or is just confused. >>> [EMAIL PROTECTED] 6/4/2003 12:28:03 PM >>> Well some of the things in there are more than a little odd such as looking up the attribute NID instead of using it directly. That is why do: OBJ_txt2nid("commonName"); when NID_commonName gets the NID directly. And calling X509_NAME_add_entry_by_NID() would avoid some yuckiness early on... Then there's that exponent 3 key. However that probably isn't the problem. Its possible that they want the old form of the certificate request which ironically has NEW in the headers. To use that form use the call PEM_write_bio_X509_REQ_NEW(). Steve. -- Dr Stephen N. Henson. Core developer of the   OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. ______________________________________________________________________ OpenSSL Project                                 http://www.openssl.org User Support Mailing List                    [EMAIL PROTECTED] Automated List Manager                           [EMAIL PROTECTED]