-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entra ID as SAML IdP Causes CodeQL to Fail with Self-Signed Certificate Found in Certificate Chain #17082
Comments
Hi @matross-gh, you need to make sure that the root certificate used to sign the self-signed certificate is available to Node on the runner. See this discussion for advice on how to do that. |
@mbg, I am not sure if I follow you, sorry! The self-signed certificate in the chain is from Microsoft Azure Federated SSO Certificate during the setup of an Azure Enterprise App. It generates a certificate issued by Microsoft Azure Federated SSO Certificate to Microsoft Azure Federated SSO Certificate for SAML with GitHub. I have converted it to .pem and setup the environment variable for Node: NODE_EXTRA_CA_CERTS=d:\certificates\cacert.pem When I launch node I issue process.env and can "see" NODE_EXTRA_CA_CERTS there. I have installed that self-signed certificate to my CodeQL server certificate store. This is a Windows 2022 server. |
Just to clarify, it sounds like you converted the self-signed certificate that is used by GHES and added it there? If so, that isn't right -- you need to take the certificate that was used to sign the certificate used by GHES and make it available to Node. The error you are getting suggests that, when the CodeQL Action is trying to connect to the API exposed by your GHES instance, it is presented with a TLS certificate that cannot be validated using any of the root certificates available to the Node runtime on the Actions runner. Therefore, it gets flagged as a self-signed certificate and rejected. I would think that this is a general issue with your Actions setup and other Actions which make use of the API would report similar errors. Here are some more instructions for how to configure things in general: actions/checkout#362 (comment) However, note that you have opened this issue on the |
@mbg Tried all those options.. that did not work. Also, actions/checkout#362 is back in 2020. Maybe updates/changes introduced or re-introduced things? Who knows... When I looked at the cert I am giving Node and my runner it IS the full chain. Something else is going on here... I did follow all GH documentation for this setup. Thanks for the time.. |
Additional Update Logged onto my Windows runner with CodeQL and fired up Node. Small code to see if Node has access to the certificate GHES API is using/after:
const tls = require('tls');
const fs = require('fs');
const ca = await fs.readFileSync(process.env.NODE_EXTRA_CA_CERTS, 'utf8');
console.log(ca); //successfully print the CA, so it exists.
const inList = tls.rootCertificates.some( cert =>{
console.log('testing ca : \n',cert);
return cert == ca;
});
console.log(`CA is ${ !inList ? 'not' : '' } in rootCertificates list...`); At the end here, I don't get a match. What is interesting is the certificate is definitly found and loaded up in Node. I copied the output from HTH |
My understanding is that If
|
yes, process.env.node_extra_ca_certs havs the path I set. I verified with that code it has the cert with the chain. I restarted the server; everything still checks outs. Also, ran a simple workflow and outputted all environment variables and I can see the node_extra_ca_certs there... Last thing I can do, then I am done because I am out of options, is to get a new certificate such that the CN of the certificate is not the name of the host. Will status here how that goes... |
@mbg Ok, got a new cert and the CN is not the computer name. CodeQL fails with: |
Environment
NOTE: Tried OIDC however GitHub 3.13.0 goes to the Azure commercial endpoints and not the government ones.
NOTE: If trying to send GH audit to EventHub, same issue. GH 3.13.0 defaults to commercial endpoints and not government
Expectation
Problem
Additional Comments / Notes
Cross-Reference for some additional context: https://security.stackexchange.com/questions/146132/self-signed-certificate-for-a-idp-initiated-saml-sso
When executing on my Windows 2022 CodeQL Server:
.\openssl s_client -showcerts -connect <your ghes server fqdn>:443
shows the self-signed certificate in the chain:
The text was updated successfully, but these errors were encountered: