Before reading @Osiris' post about the existing bug report , i was troubleshooting this from a Python perspective:
I don't think any of that would matter. That error gets triggered when Cryptography checks for FIPS support, and the underlying bindings don't have the right symbols.
Stuff like this usually means your bindings or core library are too old and don't meet the minimum version requirements. Most of the things you've posted suggest to me that you should be meeting these requirements. To be safe, I double checked the OpenSSL source - and they have had this for years in the various branches, so I am pretty sure it's not an issue with OpenSSL itself.
Looking at the history of Cryptography - in April of 2023 they migrated the fips detection to Rust.
It is possible the existing bug that Osiris found does not affect earlier releases. It very well might be affected in the same exact way - but the checks are completely different (see Move is_fips logic to Rust by alex · Pull Request #8822 · pyca/cryptography · GitHub) so I would not be surprised if you are able to use a version of Cryptography prior to that date.
So... I would try the following based on cryptography · PyPI releases as a potential stopgap solution:
If I understand the FreeBSD bugreport correctly, it's a linking problem. Thus recompiling with the correct linker "instructions" (I don't have that deep a knowledge about linking and stuff though) could fix it. Unfortunately the issue is with FreeBSD and how the compiler/linker/et c. is instructed, thus currently recompiling doesn't have any use indeed. But hopefully in the future it does.
Well there are two problems here:
1- The underling linking problem you discovered, which could potentially be fixed as you suggested
2- The Rust code will raise the exception as it checks for fips support due to the implementation details of that code. It is possible the previous python check will not raise an exception and simply determine fips is not supported. I didn't dig in too deep to that PR or the code that would invoke it, because I am lazy -- when I find stuff like that it's just way faster and easier to actually test the previous version than to visually audit the code for compatabilty.
That confirms the incorrect linking. It should link to libssl.so.12 and libcrypto.so.12 apparently.
But as mentioned a few minutes ago, you could check out the bug report. One user mentions success with the current Ports. Although I'm not sure what has been updated exactly to get it fixed.
Your post was interesting, and I did follow your links. But I don't have pip installed, and that's not the direction I want to go in. I'd like to solve the issue, not install some other competing packaging system.
I found Osiris' linking info much more interesting, and it also makes a lot more sense. I have just over two weeks for this linking issue to be solved before my cert expires
Um... Can you explain that like I'm five? I'm honestly not sure what you mean.
What did you do? What did you revert to?
Sorry to be so thick, I've been having ongoing health issues (hence disappearing for over a week).
Did you revert to an older Python? Which version? How? Or an older Certbot? Or back to OpenSSL 1?
Over the last week, I even tried recompiling everything I had installed without success. I'd love to know what you did so I can do the same without breaking anything else!
I'm up to date with the current ports (last checked a couple of minutes ago) but still no luck
Try the advice in the comment above. If that does not affect your Certbot version, try installing Certbot from the pip instructions and then - in the same virtualenv - pip install "cryptography==40.0.2"
ELI5: Cryptography changed how they check for that openssl flag in the next release, offloading it from Python into Rust. The Rust version tries to address the broken c library linking on every invocation to test for FIPs support, so it will always raise the exception. The earlier Python version does not seem to interact with the bindings like that, or catches the exception within Python, so you should be able to use it. There are two issues here - (i) the underlying bindings being broken, and (ii) the way that Python tests for this flag in Rust is broken as it has fatal errors if the bindings have issues. Downgrading does not fix the first (bigger) issue, but should avoid the second issue.
The problem is that your existing packaging system is broken due to incompatibilities and misconfigurations in their ports. IMHO, the only way to really fix this is by filing tickets with the maintainers for those packages (which already exist as @Osiris pointed out) – otherwise you'll be doing a lot of work to either (i) fix the port and risk that being overwritten by an update or potentially breaking other software that relies on it, or (ii) correctly compile and install a dedicated version of OpenSSL, Python, the bindings, and Certbot/etc that are all built against each other in their own sandboxed environment.
The easiest and most lasting fix, IMHO, will be to use install Certbot via pip and then reinstall an earlier version of the cryptography package. Because certbot and cryptography will be installed by pip into their own virtualenv, they won't update/upgrade without your explicit interaction and should be immune from any distribution upgrades.
