[OpenSSL] LotW Certificate import fails

[phl0]

At least HB9WDF reported that LotW cert upload fails with web server running PHP8.1 / OpenSSL 3. The application logs show an error like:

INFO - 2023-04-19 21:10:53 --> Model "LotwCert" initialized
ERROR - 2023-04-19 21:10:54 --> Severity: Warning --> Undefined array key "cert" /var/www/cloudlog/application/controllers/Lotw.php 406
ERROR - 2023-04-19 21:10:54 --> error:0308010C:digital envelope routines::unsupported

This seems to be a problem of recent OpenSSL versions and probably LotW using outdated security and hashing algorithms for their certificates. As of now it seems there is no workaround besides enabling the legacy options in SSL config /etc/ssl/openssl.cnf:

diff -purN openssl.cnf.orig openssl.cnf
--- openssl.cnf.orig    2023-04-19 23:14:57.860323988 +0200
+++ openssl.cnf 2023-04-19 23:14:30.976378880 +0200
@@ -57,6 +57,7 @@ ssl_conf = ssl_sect
 # List of providers to load
 [provider_sect]
 default = default_sect
+legacy = legacy_sect

 # The fips section name should match the section name inside the
 # included fipsmodule.cnf.
@@ -71,7 +72,10 @@ default = default_sect
 # OpenSSL may not work correctly which could lead to significant system
 # problems including inability to remotely access the system.
 [default_sect]
-# activate = 1
+activate = 1
+
+[legacy_sect]
+activate = 1

Taken from https://stackoverflow.com/a/73858615 resp. https://gist.github.com/rdh27785/97210d439a280063bd768006450c435d.

This enables legacy options in SSL. After doing the changes the web server / PHP application needs a restart. This ist definitely only a temporary solution because we should not touch these settings imho. Not sure if LotW uses more recent algos in newer certs?

According to https://www.openssl.org/docs/manmaster/man1/openssl-pkcs12.html we can extract data from a cert file with -info. So maybe there is someone out there who has a recent LotW certificate and could run

$ openssl pkcs12 -in Callsign_nopass.p12 -info

on his p12 file (extracted without password from tqsl application) and show the info about the algorithms in use? My cert is from 2021 and maybe ARRL uses more recent algorithms in newer certs?!

The (probably) relevant sections are:

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

The RC2_CBC algos are definitely deprecated and causing the issues here.

After all I think this is more related to the OpenSSL version than the PHP version but hey ...

P.S.: Please do not post private key data :)

[phl0]

Digged though my LotW certificates and also the most recent one (from 2022) uses SHA1And40BitRC2-CBC. So I guess they are still using it ... -.-

[phl0]

Renamed as it is an OpenSSL issue definitely. The stuff breaks at least with OpenSSL 3.0.2:

On my machines where it is working I have OpenSSL 1.1.1f:

[AndreasK79]

Seems like tQSL also went for the legacy move: https://sourceforge.net/p/trustedqsl/tqsl/ci/2368dd6c64e8aa57c4a939b169c979c53cd97ead/

That means no other solution so far :(

[phl0]

Darn. This means we could also get stuck with systems that upgrade OpenSSL to more recent versions :(

[phl0]

The RC2 algorithms have been deprecated with release of OpenSSL 3. See: https://www.openssl.org/docs/man3.1/man7/migration_guide.html

[phl0]

That means no other solution so far :(

As long as ARRL/LotW built around deprecated algorithms not ... -.-

[magicbug]

Yeah sadly not much we can do about this one, balls in ARRLs court.

[phl0]

Yeah sadly not much we can do about this one, balls in ARRLs court.

Yeah apparently.

[magicbug]

I'm tagging this as not a bug but also not deleting it.

[lu1aax]

Hi, if your have this line commented out with # in openssl.cnf

openssl_conf = openssl_init

You must uncomment it

openssl_conf = openssl_init

[violarulan]

Hi, if your have this line commented out with # in openssl.cnf

openssl_conf = openssl_init

You must uncomment it

openssl_conf = openssl_init

I'm using Archlinux and it has already been uncommented.

After some research, I solved it by adding some additional support for openssl.

For anyone having the same issue:

First you have to find where your openssl.cnf is.

 $ php --info | grep "Openssl"
Openssl default config => /etc/ssl/openssl.cnf

Then open it with your editor.

Uncomment #openssl_conf = openssl_init as mentioned above.

Then if it still fails, add/modify the following:

[default_sect]
activate = 1
[legacy_sect]
activate = 1
[provider_sect]
default = default_sect
legacy = legacy_sect

credit: https://stackoverflow.com/questions/73832854/php-openssl-pkcs12-read-error0308010cdigital-envelope-routinesunsupported

[radnor]

I had to uncomment providers = provider_sect as well as uncommenting [providers_sect]:

[openssl_init]
# providers = provider_sect

# List of providers to load
# [provider_sect]
default = default_sect
legacy = legacy_sect

[phl0]

Update

There is a release candidate 2.7 for tqsl application (not published yet). The release notes say:

12. Update the cryptographic algorithms used for saving callsign certificates from RC2 to AES-256.

Using this version and exporting the certificates we are successful with importing these into Cloudlog without tuning OpenSSL parameters. The exported certificate(s) are now based on AES-256 instead of RC-2 which was deprecated. The cert now contains:

PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
[...]
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256

No need to (re-)request new certificates. Just re-exporting them using tqsl-2.7 is required.

We should close this issue once tqsl-2.7 is published officially.

[magicbug]

Yay

[phl0]

tqsl 2.7 (and even 2.7.1) has been released. With this version certificates can be exported and imported into CL without issues. So I close here.