If I understand your process correctly,  the reboot is what is putting you
into a true FIPS environment.  Which is what is happening when we use
MAAS/curtin to FIPS enable and deploy machines.

The CHACHA cipher is being rejected.

On Fri, Oct 6, 2023, 4:23 PM John A Meinel <email address hidden>
wrote:

> So at a minimum, this was user error. It seems that openssl s_client
> -cipher is for TLS v1.2, since we are testing TLS v1.3 you have to use:
> $ openssl s_client i -connect 54.91.83.198:17070
>
> I was able to bootstrap to Jammy on AWS and saw that I was able to
> connect using chacha.
>
> After bootstrapping a Jammy controller, I then added a model to test more
> VMs using the preload:
> $ juju model-defaults --file config.yaml
> $ juju add-model test
> Added 'test' model on aws/us-east-1 with credential 'jam-aws' for user
> 'admin'
> $ juju model-config cloudinit-userdata
> preruncmd:
>   - pro refresh config
>   - pro attach MYSECRET
>   - pro enable usg --assume-yes
>   - pro enable fips-updates --assume-yes
>
>
> Then as that machine started, I did confirm that the fips steps ran in
> /var/log/cloud-init-output.log
> ...
> Visit https://ubuntu.com/security/certifications/docs/usg for the next
> steps
> One moment, checking your subscription first
> Updating package lists
> Installing FIPS Updates packages
> FIPS Updates enabled
> A reboot is required to complete install.
> + install -D -m 644 /dev/null /var/lib/juju/nonce.txt
>
>
> However, it successfully downloads the agent binaries and gets set up (it
> is slow, but it works).
>
> Now it did say that I needed to reboot to take effect, but also:
> $ openssl s_client -ciphersuites "TLS_CHACHA20_POLY1305_SHA256"
> 172.30.2.156:17070
> ...
> ---
> Post-Handshake New Session Ticket arrived:
> SSL-Session:
>     Protocol  : TLSv1.3
>     Cipher    : TLS_CHACHA20_POLY1305_SHA256
> ...
>
>
> I even create a Focal LXD container on that machine, and by default it
> negotiated:
> SSL-Session:
>     Protocol  : TLSv1.3
>     Cipher    : TLS_AES_128_GCM_SHA256
> but if I forced it, I could get:
> SSL-Session:
>     Protocol  : TLSv1.3
>     Cipher    : TLS_CHACHA20_POLY1305_SHA256
>
>
> Now, post reboot things did change:
> ubuntu@ip-172-30-4-160:~$ openssl s_client -ciphersuites
> "TLS_CHACHA20_POLY1305_SHA256" 172.30.2.156:17070
> CONNECTED(00000003)
> 140197754987776:error:0607B0C8:digital envelope
> routines:EVP_CipherInit_ex:disabled for FIPS:../crypto/evp/evp_enc.c:227:
> 140197754987776:error:14202006:SSL routines:derive_secret_key_and_iv:EVP
> lib:../ssl/tls13_enc.c:419:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 160 bytes and written 309 bytes
> Verification: OK
> ---
> New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
>
> Though in the LXC container:
> SSL-Session:
>     Protocol  : TLSv1.3
>     Cipher    : TLS_CHACHA20_POLY1305_SHA256
>
>
> However, back in the host, if I don't force CHACHA:
> SSL-Session:
>     Protocol  : TLSv1.3
>     Cipher    : TLS_AES_128_GCM_SHA256
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2002841
>
> Title:
>   Juju agent cannot download from FIPS enabled LXD containers in
>   Openstack Deployment
>
> Status in Canonical Juju:
>   Triaged
> Status in lxd:
>   New
>
> Bug description:
>   As the title suggests, when we have a FIPS enabled deployment, the LXD
>   subordinate units of the Openstack layer cannot download the Juju
>   agent binary from the Juju controller. Our best guess into what might
>   be causing this is that there is a TLS v1.3 cipher mismatch between
>   what the internal Juju controller web server offers, the go webserver,
>   which has a (known bug around NIST-approved
>   ciphers)[https://github.com/golang/go/issues/54072] and what the FIPS
>   compliant lxd container can accept thus leading to the bellow error.
>
>   From the LXD console.log of the respective container:
>   ```
>   [ 4115.002314] cloud-init[979]: + echo Attempt 181 to download agent
> binaries from '
> https://10.246.165.124:17070/model/acce9b42-a01e-4eb0-87fa-abc0506e8c6b/tools/2.9.37-ubuntu-amd64'..
> .\n
>   [ 4115.002482] cloud-init[979]: Attempt 181 to download agent binaries
> from '
> https://10.246.165.124:17070/model/acce9b42-a01e-4eb0-87fa-abc0506e8c6b/tools/2.9.37-ubuntu-amd64'.
> ..
>   [ 4115.002648] cloud-init[979]: + curl -sSf --connect-timeout 20
> --noproxy * --insecure -o
> /var/lib/juju/tools/2.9.37-ubuntu-amd64/tools.tar.gz
> https://10.246.165.124:17070/model/acce9b42-a01e-4eb0-87fa-abc0506e8c6b/tools/2.9.37-ubuntu-amd64
>   [ 4115.039889] cloud-init[979]: curl: (35) error:0607B0C8:digital
> envelope routines:EVP_CipherInit_ex:disabled for FIPS
>
>   ```
>
>   The container then enters this infinite loop and the deployment gets
>   stuck. The solutions QA team has a reproducer and an active
>   environment with this bug, both that can be made available if
>   requested.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/2002841/+subscriptions
>
>