| Summary: | CU175 Testing - Generating new Root/Host certificates on IPSec fails | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Adolf Belka <adolf.belka> |
| Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | Major Usability | ||
| Priority: | - Unknown - | CC: | michael.tremer, peter.mueller |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
|
Description
Adolf Belka
2023-06-03 10:41:37 UTC
It was reported in the forum thread that adding the line unique_subject = yes to the file /var/ipfire/certs/index/txt.attr allowed the certificate set to be successfully created again. Confirmed that this was the case but after the certificate set has been built that file is cleared and so it is not a permanent solution that can easily be built into IPFire. If the x509 was created but then a change was required and it was removed then that index.txt.attr file would have to have the line added back in by the user before trying to create the certificate set. Adding the -legacy option to all the openssl commands in vpnmain.cgi that worked on a pkcs (.p12) certificate did not solve the problem. Adding the -legacy option to every openssl command in vpnmain.cgi allowed the certificate set to be successfully built. I did a test where I left all the openssl commands dealing with a pkcs with the -legacy option. Then I added the -legacy option to each of the remaining openssl commands one at a time but this never solved the problem, so more than one of the non pkcs openssl commands needs to have the -legacy option added. As the -legacy command is unlikely to break anything, the best solution is to add the -legacy option to every openssl command in vpnmain.cgi. I will create a patch for that. I am not sure if I did not look at the result well yesterday or if I have made an error somewhere but today putting -legacy into every openssl command in vpnmain.cgi has resulted in the creation of the Root certificate but not the host certificate. Nothing obvious in the messages log. Will have a careful look through the changes, maybe re-start with a new vpnmain.cgi file Copied a fresh version of vpnmain.cgi, with the -legacy options included in every openssl command, into the vm testbed IPFire and the same thing happened. So yesterday I missed that putting the -legacy options into every openssl command created the Root certificate but not the Host certificate. I will have to remove the -legacy option from the openssl commands that look to be related to the host certficate to see what allows both to be created. I managed to figure things out with some debugging and testing some openssl commands out. The commands starting with "openssl ca" do not recognise the -legacy option and just stop without doing anything. This resulted in the cacrl file not being created. If the -legacy option is not used on those "openssl ca" commands then the openssl error about unique_subject is shown. The solution in the end is to use the -legacy option for all the openssl commands that are related to pkcs12 (.p12) files as any of these that come from an earlier Core Update with openssl-1.1.1x will have a problem being accessed bu openssl-3.x the setting unique_subject = yes has been added into the cleanssldatabase subroutine in vpnmain.cgi. The above combination has been tested out on the vm testbed successfully. Patch submitted to dev mailing list and patchwork. https://lists.ipfire.org/pipermail/development/2023-June/016004.html https://patchwork.ipfire.org/project/ipfire/patch/20230603140541.13834-1-adolf.belka@ipfire.org/ https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=94aa82fa619448229737bf545b768f0ca7177b0c Thank you very much! I'll update the draft for the C175 release announcement accordingly. Merged into Core Update 175 Testing Tested in CU175 Testing. Fix verified to be working. Core Update 175 Released. |