Bug #7509
closed
Inconsistent stored line endings in CAs
0%
Description
Hello guys,
First of all, I'm not an expert in certs/security by any means, so please be gentle. Also, I'm using the official Netgate pfSense images on AWS, I'm not 100% sure this applies to pfSense OSS or I should contact Netgate directly.
I am experiencing a very strange issue with the Certificate Manager and line endings of stored CAs:
- I create a CA and two intermediate CAs based on the first using the web interface. Then a couple of certificates based on the intermediate CAs.
- If I download now the crt/key files for the CAs and Certs, I observe that they use LF line endings
- Now I can do an edit of one of the CAs (e.g. its name), apply, then download again the crt/key files. Now I see those being encoded with CRLF line endings.
- The certificates still show the LF line endings if I download them.
- Now it gets really weird: if in some OpenVPN configuration I use the Client Export to get a config file for my clients, the ovpn file ends up with a mix of CRLF and LF line endings, since the CAs now have CRLF endings and Certificates do have LF endings.
I suppose this happens because I can edit the CAs, but the generated Certificates cannot be edited in any way, just be downloaded the crt/key files. Some code in the path from the web form to storage messes up the line endings for CAs.
I have tested this in both 2.3.2 and latest stable 2.3.3 with the AWS Netgate official image.
Regards,
Diego
Updated by Diego Louzán over 7 years ago
As an addendum, I checked the release notes of the last versions and could not find anything related to this. The closest I found was this issue marked as resolved: https://redmine.pfsense.org/issues/2800, you can see I made a comment there.
Updated by Diego Louzán over 7 years ago
I have just found that this seems to affect all input forms: if I enable "Enable authentication of TLS packets." in my OpenVPN config and let pfSense auto generate the OpenVPN static key, then exporting the ovpn config will have proper line endings. But as soon as I make any kind of edit to my OpenVPN server config, this key will then be saved with wrong endings, and then exporting again my ovpn config will have mixed LF and CRLF endings.
I'm at a loss right now, I'm not aware of any browser settings that might be influencing this, isn't this a server input validation issue?
Updated by Phillip Davis over 7 years ago
"Now it gets really weird: if in some OpenVPN configuration I use the Client Export to get a config file for my clients, the ovpn file ends up with a mix of CRLF and LF line endings"
Does that cause the OpenVPN client to not load the configuration/certificate?
Or to break in some other way?
I am just asking because your analysis is all very interesting, but it never actually mentions what breaks as as result of the inconsistent CR/LF behavior.
Updated by Kill Bill over 7 years ago
Pretty much a duplicate of #5306. This should be fixed in 2.4 at least as far as XML packages are concerned by https://github.com/pfsense/pfsense/pull/3605 - as for the rest, I don't have time for this ATM. The function is there, someone needs to go through the code and use it.
Updated by Diego Louzán over 7 years ago
Phillip Davis wrote:
Does that cause the OpenVPN client to not load the configuration/certificate?
Or to break in some other way?I am just asking because your analysis is all very interesting, but it never actually mentions what breaks as as result of the inconsistent CR/LF behavior.
That is a valid question. The truth is that I'm having some issues setting up an OpenVPN server, and in the process of debugging it I found out about the line endings issue. I have learned the hard way that mixing line endings causes all kinds of weird issues in scripts and configs, so I would expect the same on OpenVPN clients. But maybe this is actually allowed by the format spec for OpenVPN?
Updated by Jim Pingle over 7 years ago
- Status changed from New to Needs Patch
- Affected Version changed from 2.3.3_1 to All
It's been that way for years (since the 1.2.x days and before). OpenVPN doesn't care at all, it reads the data just fine.
Any issue you have with intermediate certificates is likely due to them not being handled properly on 2.3.2. On 2.3.3 and later they work fine.
If someone wants to work up a patch to fix the line ending handling in OpenVPN, have at it.