** Description changed:
- Regression introduced between 0.4.12-1.1build2 → 0.4.12-1.1ubuntu1 .
- The ubuntu1 patch added a fix for a segfault during signing on OpenSSL
- 3.0.12–3.0.13 (cherry-picked from 0.4.13). This appears to have broken
- the TPM2 auth session setup path.
+ [ Impact ]
- Key log (wpa_supplicant):
+ The libp11 SRU for LP #2158304 (0.4.12-1.1ubuntu1, in noble-updates
+ since 2026-08-06) backported a workaround that calls
+ ENGINE_set_default_string(engine, "PKEY_CRYPTO") in load_privkey(). It
+ is never undone, so once a key is loaded through the PKCS#11 engine,
+ that engine stays the process-wide default for RSA and EC for the life
+ of the process.
- tls_connection_set_params: Clearing pending SSL error: error:43000005:PKCS#11
module::General Error
- tls_connection_set_params: Clearing pending SSL error: error:13000080:engine
routines::failed loading private key
-
ERROR:esys_crypto:src/tss2-esys/esys_crypto_ossl.c:723:iesys_cryptossl_pk_encrypt()
ErrorCode (0x00070001) Could not create rsa key.
- ERROR: Esys_StartAuthSession: esapi:Catch all for all errors not otherwise
specified
- ERROR: Could not start Auth Session with the TPM.
- ERROR: Error unsealing wrapping key
- ENGINE: cannot load private key with id
'pkcs11:token=scep-client;object=client-key;type=private'
[error:03000096:digital envelope routines::operation not supported for this
keytype]
- EAP-TLS: Failed to initialize SSL.
+ Later provider-path code then gets a legacy, engine-backed context:
+ EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL) succeeds but
+ EVP_PKEY_fromdata_init() fails with
- Steps to reproduce:
+ error:03000096:digital envelope routines:fromdata_init:operation not
+ supported for this keytype
- 1. Ubuntu 24.04 with TPM2-backed SCEP certificate in PKCS#11 (via
opensc-pkcs11.so, STMicro TPM)
- 2. Configure WPA2-Enterprise EAP-TLS using a pkcs11: URI for the private key
- 3. Upgrade libengine-pkcs11-openssl from 0.4.12-1.1build2 →
0.4.12-1.1ubuntu1
- 4. Attempt Wi-Fi connection → fails as above
+ This breaks EAP-TLS with TPM-backed PKCS#11 keys: wpa_supplicant loads
+ the Wi-Fi key through the engine, and tpm2-pkcs11's tpm2-tss code then
+ fails its own unrelated RSA operation while authorising the same key.
+ The reporter downgraded to 0.4.12-1.1build2 to get back online.
+
+ Upstream confirmed the problem in OpenSC/libp11#676 and closed it
+ without a libp11-side fix: the obvious cleanup is not a reference-
+ counted inverse and would clobber registrations made elsewhere.
+
+ This upload drops the backported patch, restoring noble's pre-SRU
+ behaviour.
+
+ [ Test Plan ]
+
+ Reproducible with SoftHSM2; no hardware required.
+
+ 1. sudo apt install softhsm2 opensc libengine-pkcs11-openssl build-
+ essential libssl-dev
+
+ 2. Create a token and import an RSA key:
+
+ openssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 365
-nodes -subj "/CN=Test"
+ softhsm2-util --init-token --free --label test --so-pin 1234 --pin 1234
+ softhsm2-util --import k.pem --token test --label testkey --id 01 --pin
1234
+
+ 3. Build a probe that loads a key through the engine, then does
+ unrelated provider-path RSA work, as tpm2-tss does internally:
+
+ cat > probe.c <<'EOF'
+ #include <stdio.h>
+ #include <openssl/engine.h>
+ #include <openssl/evp.h>
+ int main(void) {
+ ENGINE_load_builtin_engines();
+ ENGINE *e = ENGINE_by_id("pkcs11");
+ ENGINE_init(e);
+ EVP_PKEY *k = ENGINE_load_private_key(e,
+ "pkcs11:token=test;object=testkey;type=private;pin-value=1234",
NULL, NULL);
+ printf("load=%s\n", k ? "OK" : "FAILED");
+ EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
+ int rc = EVP_PKEY_fromdata_init(c);
+ printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
+ return rc > 0 ? 0 : 1;
+ }
+ EOF
+ gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
+
+ 4. ./probe
+
+ 0.4.12-1.1ubuntu1: fromdata_init=-2 -> POLLUTED, and each key load prints
"Workaround for OpenSSL 3.0.13 30 Jan 2024 enabled" to stderr.
+ 0.4.12-1.1ubuntu2: fromdata_init=1 -> CLEAN, no workaround message.
+
+ [ Where problems could occur ]
+
+ This upload reintroduces the segfault that 0.4.12-1.1ubuntu1 fixed:
+ signing through the OpenSSL PKCS#11 engine will again crash on noble's
+ OpenSSL 3.0.13, as reported in LP #2158304, LP #2119094, LP #2067163 and
+ LP #2097330.
+
+ - Who is actually affected is unverified. Users signing via a PKCS#11
+ token may have silently picked up a working setup since 2026-08-06 and
+ would lose it on upgrade, possibly inside automated pipelines where it
+ surfaces as a crash rather than an error. But nobody has reported being
+ fixed by the SRU: LP #2119094's noble task is still Triaged with no
+ comment since 2026-05-19, and LP #2067163 and LP #2097330 have had no
+ activity since they were filed. The only confirmed verification is my
+ own, with a YubiHSM 2. That exposure is real but unquantified, unlike
+ this regression, which has a named reporter and a confirmed workaround.
+
+ - The crash is conditional, which bounds the blast radius. OpenSSL
+ commit 2b74e75, present only in 3.0.12 and 3.0.13, clears the engine
+ binding on the key returned by ENGINE_load_private_key(), dropping
+ libp11's functional reference. Only applications that then release their
+ own reference before using the key take the count to zero and tear down
+ the PKCS#11 context while the key is in use: sbsign, sbvarsign,
+ osslsigncode, Apache mod_ssl. Applications holding their reference until
+ teardown are unaffected either way - the openssl CLI, wpa_supplicant,
+ libcurl, nginx, libpq.
+
+ - No automated test catches this, in either direction. Nothing in the
+ openssl suite signs with an engine-loaded key, and libp11's autopkgtest
+ signs through the openssl CLI, which holds its reference, so it passes
+ with the workaround present and removed. Proposed-migration will be
+ green whichever state noble is in. Verification has to be manual.
+
+ - This is only half the fix. It clears the regression by returning noble
+ to its pre-SRU state and relies on a follow-up openssl SRU to fix the
+ segfault at its source. If that upload is rejected or delayed, noble
+ stays in the crashing state rather than reaching the state in the last
+ two rows below. Accepted, not overlooked.
+
+ - The version goes up while the code goes back. 0.4.12-1.1ubuntu2
+ removes the only delta 0.4.12-1.1ubuntu1 added, so its binaries should
+ match 0.4.12-1.1build2. The archive build2 engine,
+ /usr/lib/<triplet>/engines-3/pkcs11.so, has md5
+ f8b19f8221e46fc26a6b2c48c6880517 - a cheap check that nothing unintended
+ crept in.
+
+ Verified with SoftHSM2 and a YubiHSM 2 (sbsign against an RSA-2048 token
+ key):
+
+ openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1build2 sbsign exits 139, no
regression
+ openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1ubuntu1 sbsign exits 0,
regression present
+ openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1build2 sbsign exits 0, no
regression
+ openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1ubuntu2 sbsign exits 0, no
regression
+
+ [ Other Info ]
+
+ - Regression introduced by libp11 0.4.12-1.1ubuntu1 (LP #2158304).
+
+ - Upstream discussion and the maintainer's recommendation:
+ OpenSC/libp11#676.
+
+ - Debian hit the same defect and fixed it in openssl, not libp11: Debian
+ bug #1074764, fixed in openssl 3.0.13-1~deb12u2 (bookworm, 2024-07-05)
+ by reverting the same commit.
+
+ - The planned openssl SRU backports
+ ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6 (openssl-3.0 branch;
+ 39ea78379826fa98e8dc8c0d2b07e2c17cd68380 on master), released upstream
+ in 3.0.14 and carried in every 3.0.x since.
+
+ [ Original report ]
+
+ - wpa_supplicant fails: "Esys_StartAuthSession: Could not create rsa key
(0x00070001)"
+ - EAP-TLS fails: "ENGINE: cannot load private key ... operation not supported
for this keytype"
+ - Affects TPM2-backed PKCS#11 certificates via opensc-pkcs11.so (STMicro TPM)
Workaround: downgrade to 0.4.12-1.1build2
- (sudo apt install libengine-pkcs11-openssl=0.4.12-1.1build2)
Environment:
- Ubuntu 24.04 Noble, OpenSSL 3.0.13
- wpa_supplicant + NetworkManager EAP-TLS
- TPM2 (STMicro), tpm2-tss 4.0.1, opensc 0.25.0~rc1
** Summary changed:
- EAP-TLS Wi-Fi broken with TPM-backed PKCS#11 keys after upgrade to
0.4.12-1.1ubuntu1
+ [SRU] EAP-TLS Wi-Fi broken with TPM-backed PKCS#11 keys after upgrade to
0.4.12-1.1ubuntu1
** Description changed:
[ Impact ]
The libp11 SRU for LP #2158304 (0.4.12-1.1ubuntu1, in noble-updates
since 2026-08-06) backported a workaround that calls
ENGINE_set_default_string(engine, "PKEY_CRYPTO") in load_privkey(). It
is never undone, so once a key is loaded through the PKCS#11 engine,
that engine stays the process-wide default for RSA and EC for the life
of the process.
Later provider-path code then gets a legacy, engine-backed context:
EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL) succeeds but
EVP_PKEY_fromdata_init() fails with
- error:03000096:digital envelope routines:fromdata_init:operation not
+ error:03000096:digital envelope routines:fromdata_init:operation not
supported for this keytype
This breaks EAP-TLS with TPM-backed PKCS#11 keys: wpa_supplicant loads
the Wi-Fi key through the engine, and tpm2-pkcs11's tpm2-tss code then
fails its own unrelated RSA operation while authorising the same key.
The reporter downgraded to 0.4.12-1.1build2 to get back online.
Upstream confirmed the problem in OpenSC/libp11#676 and closed it
without a libp11-side fix: the obvious cleanup is not a reference-
counted inverse and would clobber registrations made elsewhere.
This upload drops the backported patch, restoring noble's pre-SRU
behaviour.
[ Test Plan ]
Reproducible with SoftHSM2; no hardware required.
1. sudo apt install softhsm2 opensc libengine-pkcs11-openssl build-
essential libssl-dev
2. Create a token and import an RSA key:
- openssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 365
-nodes -subj "/CN=Test"
- softhsm2-util --init-token --free --label test --so-pin 1234 --pin 1234
- softhsm2-util --import k.pem --token test --label testkey --id 01 --pin
1234
+ openssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 365
-nodes -subj "/CN=Test"
+ softhsm2-util --init-token --free --label test --so-pin 1234 --pin 1234
+ softhsm2-util --import k.pem --token test --label testkey --id 01 --pin
1234
3. Build a probe that loads a key through the engine, then does
unrelated provider-path RSA work, as tpm2-tss does internally:
- cat > probe.c <<'EOF'
- #include <stdio.h>
- #include <openssl/engine.h>
- #include <openssl/evp.h>
- int main(void) {
- ENGINE_load_builtin_engines();
- ENGINE *e = ENGINE_by_id("pkcs11");
- ENGINE_init(e);
- EVP_PKEY *k = ENGINE_load_private_key(e,
- "pkcs11:token=test;object=testkey;type=private;pin-value=1234",
NULL, NULL);
- printf("load=%s\n", k ? "OK" : "FAILED");
- EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
- int rc = EVP_PKEY_fromdata_init(c);
- printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
- return rc > 0 ? 0 : 1;
- }
- EOF
- gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
+ cat > probe.c <<'EOF'
+ #include <stdio.h>
+ #include <openssl/engine.h>
+ #include <openssl/evp.h>
+ int main(void) {
+ ENGINE_load_builtin_engines();
+ ENGINE *e = ENGINE_by_id("pkcs11");
+ ENGINE_init(e);
+ EVP_PKEY *k = ENGINE_load_private_key(e,
+ "pkcs11:token=test;object=testkey;type=private;pin-value=1234",
NULL, NULL);
+ printf("load=%s\n", k ? "OK" : "FAILED");
+ EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
+ int rc = EVP_PKEY_fromdata_init(c);
+ printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
+ return rc > 0 ? 0 : 1;
+ }
+ EOF
+ gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
4. ./probe
- 0.4.12-1.1ubuntu1: fromdata_init=-2 -> POLLUTED, and each key load prints
"Workaround for OpenSSL 3.0.13 30 Jan 2024 enabled" to stderr.
- 0.4.12-1.1ubuntu2: fromdata_init=1 -> CLEAN, no workaround message.
+ 0.4.12-1.1ubuntu1: fromdata_init=-2 -> POLLUTED, and each key load prints
"Workaround for OpenSSL 3.0.13 30 Jan 2024 enabled" to stderr.
+ 0.4.12-1.1ubuntu2: fromdata_init=1 -> CLEAN, no workaround message.
[ Where problems could occur ]
This upload reintroduces the segfault that 0.4.12-1.1ubuntu1 fixed:
signing through the OpenSSL PKCS#11 engine will again crash on noble's
- OpenSSL 3.0.13, as reported in LP #2158304, LP #2119094, LP #2067163 and
- LP #2097330.
+ OpenSSL 3.0.13, as reported in LP: #2158304, LP #2119094, LP: #2067163
+ and LP: #2097330.
- Who is actually affected is unverified. Users signing via a PKCS#11
token may have silently picked up a working setup since 2026-08-06 and
would lose it on upgrade, possibly inside automated pipelines where it
surfaces as a crash rather than an error. But nobody has reported being
fixed by the SRU: LP #2119094's noble task is still Triaged with no
- comment since 2026-05-19, and LP #2067163 and LP #2097330 have had no
+ comment since 2026-05-19, and LP #2067163 and LP: #2097330 have had no
activity since they were filed. The only confirmed verification is my
own, with a YubiHSM 2. That exposure is real but unquantified, unlike
this regression, which has a named reporter and a confirmed workaround.
- The crash is conditional, which bounds the blast radius. OpenSSL
commit 2b74e75, present only in 3.0.12 and 3.0.13, clears the engine
binding on the key returned by ENGINE_load_private_key(), dropping
libp11's functional reference. Only applications that then release their
own reference before using the key take the count to zero and tear down
the PKCS#11 context while the key is in use: sbsign, sbvarsign,
osslsigncode, Apache mod_ssl. Applications holding their reference until
teardown are unaffected either way - the openssl CLI, wpa_supplicant,
libcurl, nginx, libpq.
- No automated test catches this, in either direction. Nothing in the
openssl suite signs with an engine-loaded key, and libp11's autopkgtest
signs through the openssl CLI, which holds its reference, so it passes
with the workaround present and removed. Proposed-migration will be
green whichever state noble is in. Verification has to be manual.
- This is only half the fix. It clears the regression by returning noble
to its pre-SRU state and relies on a follow-up openssl SRU to fix the
segfault at its source. If that upload is rejected or delayed, noble
stays in the crashing state rather than reaching the state in the last
two rows below. Accepted, not overlooked.
- The version goes up while the code goes back. 0.4.12-1.1ubuntu2
removes the only delta 0.4.12-1.1ubuntu1 added, so its binaries should
match 0.4.12-1.1build2. The archive build2 engine,
/usr/lib/<triplet>/engines-3/pkcs11.so, has md5
f8b19f8221e46fc26a6b2c48c6880517 - a cheap check that nothing unintended
crept in.
Verified with SoftHSM2 and a YubiHSM 2 (sbsign against an RSA-2048 token
key):
- openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1build2 sbsign exits 139, no
regression
- openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1ubuntu1 sbsign exits 0,
regression present
- openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1build2 sbsign exits 0, no
regression
- openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1ubuntu2 sbsign exits 0, no
regression
+ openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1build2 sbsign exits 139, no
regression
+ openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1ubuntu1 sbsign exits 0,
regression present
+ openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1build2 sbsign exits 0, no
regression
+ openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1ubuntu2 sbsign exits 0, no
regression
[ Other Info ]
- Regression introduced by libp11 0.4.12-1.1ubuntu1 (LP #2158304).
- Upstream discussion and the maintainer's recommendation:
OpenSC/libp11#676.
- Debian hit the same defect and fixed it in openssl, not libp11: Debian
bug #1074764, fixed in openssl 3.0.13-1~deb12u2 (bookworm, 2024-07-05)
by reverting the same commit.
- The planned openssl SRU backports
ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6 (openssl-3.0 branch;
39ea78379826fa98e8dc8c0d2b07e2c17cd68380 on master), released upstream
in 3.0.14 and carried in every 3.0.x since.
[ Original report ]
- wpa_supplicant fails: "Esys_StartAuthSession: Could not create rsa key
(0x00070001)"
- EAP-TLS fails: "ENGINE: cannot load private key ... operation not supported
for this keytype"
- Affects TPM2-backed PKCS#11 certificates via opensc-pkcs11.so (STMicro TPM)
Workaround: downgrade to 0.4.12-1.1build2
Environment:
- Ubuntu 24.04 Noble, OpenSSL 3.0.13
- wpa_supplicant + NetworkManager EAP-TLS
- TPM2 (STMicro), tpm2-tss 4.0.1, opensc 0.25.0~rc1
** Description changed:
[ Impact ]
The libp11 SRU for LP #2158304 (0.4.12-1.1ubuntu1, in noble-updates
since 2026-08-06) backported a workaround that calls
ENGINE_set_default_string(engine, "PKEY_CRYPTO") in load_privkey(). It
is never undone, so once a key is loaded through the PKCS#11 engine,
that engine stays the process-wide default for RSA and EC for the life
of the process.
Later provider-path code then gets a legacy, engine-backed context:
EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL) succeeds but
EVP_PKEY_fromdata_init() fails with
error:03000096:digital envelope routines:fromdata_init:operation not
supported for this keytype
This breaks EAP-TLS with TPM-backed PKCS#11 keys: wpa_supplicant loads
the Wi-Fi key through the engine, and tpm2-pkcs11's tpm2-tss code then
fails its own unrelated RSA operation while authorising the same key.
The reporter downgraded to 0.4.12-1.1build2 to get back online.
Upstream confirmed the problem in OpenSC/libp11#676 and closed it
without a libp11-side fix: the obvious cleanup is not a reference-
counted inverse and would clobber registrations made elsewhere.
This upload drops the backported patch, restoring noble's pre-SRU
behaviour.
[ Test Plan ]
Reproducible with SoftHSM2; no hardware required.
1. sudo apt install softhsm2 opensc libengine-pkcs11-openssl build-
essential libssl-dev
2. Create a token and import an RSA key:
openssl req -x509 -newkey rsa:2048 -keyout k.pem -out c.pem -days 365
-nodes -subj "/CN=Test"
softhsm2-util --init-token --free --label test --so-pin 1234 --pin 1234
softhsm2-util --import k.pem --token test --label testkey --id 01 --pin
1234
3. Build a probe that loads a key through the engine, then does
unrelated provider-path RSA work, as tpm2-tss does internally:
cat > probe.c <<'EOF'
#include <stdio.h>
#include <openssl/engine.h>
#include <openssl/evp.h>
int main(void) {
ENGINE_load_builtin_engines();
ENGINE *e = ENGINE_by_id("pkcs11");
ENGINE_init(e);
EVP_PKEY *k = ENGINE_load_private_key(e,
"pkcs11:token=test;object=testkey;type=private;pin-value=1234",
NULL, NULL);
printf("load=%s\n", k ? "OK" : "FAILED");
EVP_PKEY_CTX *c = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL);
int rc = EVP_PKEY_fromdata_init(c);
printf("fromdata_init=%d -> %s\n", rc, rc > 0 ? "CLEAN" : "POLLUTED");
return rc > 0 ? 0 : 1;
}
EOF
gcc -Wno-deprecated-declarations probe.c -o probe -lcrypto
4. ./probe
0.4.12-1.1ubuntu1: fromdata_init=-2 -> POLLUTED, and each key load prints
"Workaround for OpenSSL 3.0.13 30 Jan 2024 enabled" to stderr.
0.4.12-1.1ubuntu2: fromdata_init=1 -> CLEAN, no workaround message.
[ Where problems could occur ]
This upload reintroduces the segfault that 0.4.12-1.1ubuntu1 fixed:
signing through the OpenSSL PKCS#11 engine will again crash on noble's
- OpenSSL 3.0.13, as reported in LP: #2158304, LP #2119094, LP: #2067163
+ OpenSSL 3.0.13, as reported in LP: #2158304, LP: #2119094, LP: #2067163
and LP: #2097330.
- Who is actually affected is unverified. Users signing via a PKCS#11
token may have silently picked up a working setup since 2026-08-06 and
would lose it on upgrade, possibly inside automated pipelines where it
surfaces as a crash rather than an error. But nobody has reported being
fixed by the SRU: LP #2119094's noble task is still Triaged with no
comment since 2026-05-19, and LP #2067163 and LP: #2097330 have had no
activity since they were filed. The only confirmed verification is my
own, with a YubiHSM 2. That exposure is real but unquantified, unlike
this regression, which has a named reporter and a confirmed workaround.
- The crash is conditional, which bounds the blast radius. OpenSSL
commit 2b74e75, present only in 3.0.12 and 3.0.13, clears the engine
binding on the key returned by ENGINE_load_private_key(), dropping
libp11's functional reference. Only applications that then release their
own reference before using the key take the count to zero and tear down
the PKCS#11 context while the key is in use: sbsign, sbvarsign,
osslsigncode, Apache mod_ssl. Applications holding their reference until
teardown are unaffected either way - the openssl CLI, wpa_supplicant,
libcurl, nginx, libpq.
- No automated test catches this, in either direction. Nothing in the
openssl suite signs with an engine-loaded key, and libp11's autopkgtest
signs through the openssl CLI, which holds its reference, so it passes
with the workaround present and removed. Proposed-migration will be
green whichever state noble is in. Verification has to be manual.
- This is only half the fix. It clears the regression by returning noble
to its pre-SRU state and relies on a follow-up openssl SRU to fix the
segfault at its source. If that upload is rejected or delayed, noble
stays in the crashing state rather than reaching the state in the last
two rows below. Accepted, not overlooked.
- The version goes up while the code goes back. 0.4.12-1.1ubuntu2
removes the only delta 0.4.12-1.1ubuntu1 added, so its binaries should
match 0.4.12-1.1build2. The archive build2 engine,
/usr/lib/<triplet>/engines-3/pkcs11.so, has md5
f8b19f8221e46fc26a6b2c48c6880517 - a cheap check that nothing unintended
crept in.
Verified with SoftHSM2 and a YubiHSM 2 (sbsign against an RSA-2048 token
key):
openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1build2 sbsign exits 139, no
regression
openssl 3.0.13-0ubuntu3.15 + libp11 0.4.12-1.1ubuntu1 sbsign exits 0,
regression present
openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1build2 sbsign exits 0, no
regression
openssl 3.0.13-0ubuntu3.16 + libp11 0.4.12-1.1ubuntu2 sbsign exits 0, no
regression
[ Other Info ]
- Regression introduced by libp11 0.4.12-1.1ubuntu1 (LP #2158304).
- Upstream discussion and the maintainer's recommendation:
OpenSC/libp11#676.
- Debian hit the same defect and fixed it in openssl, not libp11: Debian
bug #1074764, fixed in openssl 3.0.13-1~deb12u2 (bookworm, 2024-07-05)
by reverting the same commit.
- The planned openssl SRU backports
ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6 (openssl-3.0 branch;
39ea78379826fa98e8dc8c0d2b07e2c17cd68380 on master), released upstream
in 3.0.14 and carried in every 3.0.x since.
[ Original report ]
- wpa_supplicant fails: "Esys_StartAuthSession: Could not create rsa key
(0x00070001)"
- EAP-TLS fails: "ENGINE: cannot load private key ... operation not supported
for this keytype"
- Affects TPM2-backed PKCS#11 certificates via opensc-pkcs11.so (STMicro TPM)
Workaround: downgrade to 0.4.12-1.1build2
Environment:
- Ubuntu 24.04 Noble, OpenSSL 3.0.13
- wpa_supplicant + NetworkManager EAP-TLS
- TPM2 (STMicro), tpm2-tss 4.0.1, opensc 0.25.0~rc1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163152
Title:
[SRU] EAP-TLS Wi-Fi broken with TPM-backed PKCS#11 keys after upgrade
to 0.4.12-1.1ubuntu1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libp11/+bug/2163152/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
