fleet should use your system cert store

^^^to alpine docs I go!

Fleet is using the cert provided in your IdP metadata, not the system store.

Right I had assumed that it took the cert from the IdP metadata and tried to validate the chain of trust (stored locally); ergo the error about "Could not verify certificate against trusted certs" I could be wrong though. 🤷

It takes the certificate in the IdP metadata and uses that as the trusted root by which it tries to validate SAML messages. Is it possible your IdP is now using a different cert and you have older metadata?

So I started by verifing the cert's chain:

openssl verify -CAfile ca-cert-DigiCert_Global_Root_CA.pem -untrusted ca-cert-DigiCertSHA2SecureServerCA.pem ssocert.pem

ssocert.pem: OK

ssocert.pem is a properly formatted PEM cert which I pulled from the SSO metadata from my IdP. I noticed the Digicert's Leaf Cert (

DigiCertSHA2SecureServerCA

) isn't in Alpine's

/etc/ssl/certs/ca-certificates.crt

which I would expect a Public CA like Digicert to be in already. I digress... So I followed some instructions on the interwebs and got it included in the

ca-certificates.crt

file. However many people are having mixed sucess with Alpine's `update-ca-certificates`: https://github.com/gliderlabs/docker-alpine/issues/30 So I suspect something about

update-ca-certificates

isn't behaving properly. 😭

Did you try verifying the signature in the SAML assertion using the cert provided in the metadata? That is I believe where the problem lies. I do not think Fleet is doing any verification of the cert chain. It assumes that you configure SSO using a cert chain that you trust.

Error message led me down the chain verification rabbit hole; however this is a good idea. Looking into what I need to do to check a SAML signature.

Yeah I think the error message may be a bit confusing. It's talking about not being able to verify the cert that was used to sign the SAML assertion against the root cert configured through your metadata.

So I spoke with my IdP admin. He exported me a new XML metadata blob. Apparently the one I was using was signed with the wrong private key. Now it works. 🤘

Sounds about right. Glad you got it working!