Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

Okay didn't have success. Double checked Alpine Linux's trust store to make sure the Digicert stuff is in there (the official Fleet continer uses Alpine) and it is.
If anyone has troubleshooting tips, send em my way!

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. :shrug:

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. :sob:

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. :metal:

Sounds about right. Glad you got it working!