Viktor,
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 openssl <subcommand> -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module). 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.
So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I got the info I need to program something and troubleshoot any encoding problems from -text output bytes that might arise. I can see that 'openssl req -in <csr> -outform DER' 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 Python's universal newlines 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.
Thanks.
Douglas Morris
