xca unusable pfx export for android / macos

[Tom Weber]

pfx files exported from xca fail to import on Android (invalid password) or MacOS

this is related to new defaults of openssl 3 and has been reported to upstream already:

https://github.com/chris2511/xca/issues/360

there's also a fix in a Pull request upstream:

https://github.com/chris2511/xca/pull/389

attached is a patch against xca-2.4.0-2 package created from this pull request which works for me.

Regards,
  Tom

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "pkcs12-encryption-algorihtm-settings.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Thomas Ward (teward)]

The issue you linked and the PR dont seem to address the same thing; this is something Upstream needs to address first, I believe, before we add code and new features to XCA via SRU or otherwise.

[Tom Weber (tomx)]

The PR gives you the option to select the encryption method for exporting password protected pfx.

Default for password protected pfx with openssl3 is AES_256_CBC - which your xca package on 22.04 produces and which fail to import on Android, MacOS and Windows.

The xca package on 20.04 uses openssl 1.x which defaults to 3DES_CBC - which can be imported on Android, MacOS and Windows.

see the -legacy Option of the current openssl-pkcs12 manpage.
Or this Thread:
https://stackoverflow.com/questions/69343254/the-password-you-entered-is-incorrect-when-importing-pfx-files-to-windows-cer
which sums it up quite nice.

This PR gives a configuration option to switch this.
I see your point in not adding options that really should be added upstream.

BUT

- I don't see reaction upstream - and i don't know if upstream is supposed to be build/tested against openssl3 (because there are openssl3 specific patches in the current .deb package).

- xca on 22.04 is broken (at least for me) as it is because I can't export anymore - which worked fine on 20.04

the patch was meant to offer just one way out of this dilemma :)

As this bug effectively breaks functionality (we ran into it by deploying a bunch of non importable client-side .pfx to android users which all failed to import) I wouldn't rate it's importance "Low"

[Thomas Ward (teward)]

Note that even this PR wont' work - the core OpenSSL needs to be enabled
with Legacy upstream - see https://github.com/chris2511/xca/issues/383
for that one.  Even if this were 'enabled' with the upstream
configuration tool, OpenSSL 'legacy' options are not enabled in XCA in
22.04+ or Debian upstream.

As a result, 383 needs handled first even for newer versions to work
properly.

Again, because this is major under the hood changes in XCA, I'm hesitant
to immediately import this as is until Upstream's taken a look - their
last commit was Sept. 7 so I'm not *too* worried about bitrot because I
know the upstream maintainer has a ton of things they work on.

Thomas

On 10/28/22 12:25, Tom Weber wrote:
> The PR gives you the option to select the encryption method for
> exporting password protected pfx.
>
> Default for password protected pfx with openssl3 is AES_256_CBC - which
> your xca package on 22.04 produces and which fail to import on Android,
> MacOS and Windows.
>
> The xca package on 20.04 uses openssl 1.x which defaults to 3DES_CBC -
> which can be imported on Android, MacOS and Windows.
>
> see the -legacy Option of the current openssl-pkcs12 manpage.
> Or this Thread:
> https://stackoverflow.com/questions/69343254/the-password-you-entered-is-incorrect-when-importing-pfx-files-to-windows-cer
> which sums it up quite nice.
>
> This PR gives a configuration option to switch this.
> I see your point in not adding options that really should be added upstream.
>
> BUT
>
> - I don't see reaction upstream - and i don't know if upstream is
> supposed to be build/tested against openssl3 (because there are openssl3
> specific patches in the current .deb package).
>
> - xca on 22.04 is broken (at least for me) as it is because I can't
> export anymore - which worked fine on 20.04
>
> the patch was meant to offer just one way out of this dilemma :)
>
> As this bug effectively breaks functionality (we ran into it by
> deploying a bunch of non importable client-side .pfx to android users
> which all failed to import) I wouldn't rate it's importance "Low"
>

[Tom Weber (tomx)]

maybe I made a mistake by including too much technical details and a patch to demonstrate where the problem is.

The main point about this bug report is:
xca 2.4 on 22.04(LTS) fails to export usable .pfx files for a majority of devices. And it fails to do so in a very unobvious way ("wrong password entered" when trying to import these .pfx on some devices)

xca 2.2 on 20.04(LTS) does not show this behaviour.

The purpose of xca is certificate management - which is quite impossible without exporting them.

So this is a serious showstopper when upgrading - not a nice to have wishlist thing.
Certificates have an expiration date and must be renewed and deployed by that deadline which simply is impossible on 22.04 / xca 2.4 right now (and worked on LTS before)

technically i'm completely with your reasoning - though it won't help people who upgraded LTS and need to renew and deploy certificates.

Importance Low doesn't seem to fit for me.

[Thomas Ward (teward)]

NOTE: This functionality was NOT available in XCA until 2.6.0. It is now available in 2.6.0-1 in Debian and will be in the jammy-backports and noble-backports pocket - once it is built and available, you can use `sudo apt-get install xca/RELEASE-backports` to install the software from the Backports pocket if you have the Backports pocket enabled.

---

Unfortunately, the problem here is that OpenSSL in Ubuntu 22.04 and later have moved those algorithms to the 'legacy' provider. Additionally, XCA 2.4.0 (and 2.5.0 in Noble currently) has no mechanism to enable legacy authentication mechanisms via OpenSSL.

Because this is now available in 2.6.0 as a **feature**, I have already started the process of making this a backport so 2.6.0-1 will be available via the Backports pocket. (It fixes a bug in upstream Git, however because this wasn't *available* in XCA, it's considered a "new feature").

Fixing XCA 2.4 *itself* to fix this is much more invasive a process because XCA has to first load the legacy provider AND change its export functionality, which is something that is not SRUable because of the extent of changes necessary to do this. Therefore, just use the Backports version which should be available within a few hours.