Certs generated by LXD-UI are not following best practices

[simondeziel]

I asked the LXD-UI (from LXD latest/edge) to generate a certificate and got one using RSA-2048 with SHA1 signature. Both are sub-optimal in terms of security. ECDSA P-384 with SHA384 would be in line with what the CLI client generates. Also, the C and ST fields in the Issuer and Subject fields should probably be dropped instead of getting invalid values.

$ openssl x509 -text -noout -in ~/Downloads/lxd-ui-v1.lxd.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:76:00:09:17:06:88:00:09:21:09:13:04:24:00:22
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = AU, ST = Some-State, O = LXD UI v1.lxd (Browser Generated)
        Validity
            Not Before: Jan 30 18:27:56 2025 GMT
            Not After : Oct 27 18:27:56 2027 GMT
        Subject: C = AU, ST = Some-State, O = LXD UI v1.lxd (Browser Generated)
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
    Signature Value:
...

I get a similarly looking certificate with Firefox 134.0.2 and Chromium 132.0.6834.83.

[edlerd]

Thanks for the report. The subject needs cleanup for sure!

I remember going back to some legacy settings for creating certs that are compatible with Mac OS at some point in the past. I will adjust to your suggested settings and test on different browsers and operating systems. Ideally we reach settings that align with best practices and work everywhere.

[simondeziel]

I remember going back to some legacy settings for creating certs that are compatible with Mac OS at some point in the past.

Oh, that's surprising considering that Apple is pushing hard for the certificate/PKI ecosystem to improve (short cert lifetime being their latest focus).

I will adjust to your suggested settings and test on different browsers and operating systems.

Thank you!

Ideally we reach settings that align with best practices and work everywhere.

Hopefully that will be without SHA1 even for macOS.

[edlerd]

Briefly looked into this. We can generate an ECC CryptoKeyPair with the web crypto API. Problem is, the crypto API does not give us a pfx file.

We currently use forge for converting the keys to pfx, but it only supports RSA. A PR to add support for ECC is open for a long time. As I can see they are mixing the generation and not using the crypto API to generate the keys yet in the PR. Maybe we should chip in and help out over there.

[vosdev]

If browser libraries are the limiting factor, what about having the cli generate the certificates instead? Step 2 in the Generate Certificate proces is to go back to the cli and add it to the trust store.

I think it would be a smoother experience to have both step 1 and step 2 on the cli so that you can combine these steps.

I personally generate certificates myself with cfssl so that I can easily set my own subjects etc. The browser generated certs are pretty ugly in terms of naming. The ability to customize these would be a lovely addition.

If you're a single user then lxd-ui-[2001_db8_3cc4_35_a6bb_6dff_fe6d_1b54].crt or lxd-ui-sub.domain.com.crt can work, but working with multiple users it gets pretty messy.