
<html><head></head><body><div class="ydp9332c13fyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div id="ydp9332c13fyiv1059073553"><div><div class="ydp9332c13fyiv1059073553ydp36eb6ad7yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div><div dir="ltr" data-setdir="false"><span>Viktor,</span></div><div dir="ltr" data-setdir="false"><span><br></span></div><div dir="ltr" data-setdir="false">Thanks for meticulously answering my questions. I know the file name encoding is not necessarily the file content encoding. If a Python program were on a Windows computer, it might show a file name encoding of UTC-16, which would make UTC-16 a good guess for what <span><span>openssl <subcommand> -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module)</span></span>. That was my conjectural thinking and a heuristic I though might be useful. I could get the name of the operating system from Python and map that to a 'native' encoding I suppose, but that's too much work for dubious gain. I'm not testing on Windows. It is enough to know that there is no easy and obvious way to accommodate -text bytes on various OSes, supposing they would be different. Maybe there is no difference. I expect think there should be on older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I knowledge I have, accept the uncertainty, and concentrate on the OS that I'm using, which is Linux. I could always extract public key parameters and expiration dates from the OS-consistent PEM form, not that I want to try.<span></span><br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">So <span>DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via <span>herongyang.com</span>, the MS line breaks are a nice touch. I got the info</span> I need to program something and troubleshoot any encoding problems from -text output bytes that might arise. I can see that <span>'openssl req -in <csr> -outform DER</span>' outputs bytes that are not to be changed. I suppose the same is true of -outform PEM. That's good to know because I was 'fixing' the received certificate (in PEM I believe) by normalizing line breaks to '\n' and then trusting <span>Python's universal newlines</span> mode to write out the big string in a variable to a file with the native OS-line-break encoding. I think I'll just write out the raw bytes as received. Funny, but I ran openssl x509 -text on the one test/staging certificate I saved to file only hours ago, and with the aforesaid 'normalization', and it displayed correctly. I know that doesn't prove that such treatment for a real certificate will work correctly for the Web server when the time comes, but my program is coming along and I know a little more about what's going on.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Thanks.<br></div><div><br></div><div class="ydp9332c13fyiv1059073553ydp36eb6ad7signature"><div>Douglas Morris<br></div></div></div></div></div></div></div></body></html>