OneLogin_Saml2_IdPMetadataParser.get_metadata not compatible with self-signed certificates #403
Labels
Comments
sergei-maertens
added a commit
to maykinmedia/python3-saml
that referenced
this issue
Apr 2, 2024
Replaced IDP metadata fetching via urllib with requests. Projects making use of requests/self-certifi set up the CA bundle to wire up additional trusted root CAs, which are picked up by requests, so this should also work properly. Upstream issue: SAML-Toolkits#403 Open Forms issue: open-formulieren/open-forms#4079
|
@sergei-maertens sorry for the delayed response. Yes, I think makes sense to support it |
|
Nice, I'll draw up a PR! |
sergei-maertens
added a commit
to maykinmedia/python3-saml
that referenced
this issue
Jul 10, 2024
Using requests allows us to easily customize the CA_BUNDLE to use when verifying the server certificate, instead of having to disable SSL certificate verification alltogether.
sergei-maertens
added a commit
to maykinmedia/python3-saml
that referenced
this issue
Oct 3, 2024
When retrieving the IDP metadata, you can now optionally specify the the capath or cafile to use for certificate verification, rather than just enabling/disabling it. This allows TLS verification of server certificates that are not in the system root store (such as when using private CAs).
sergei-maertens
added a commit
to maykinmedia/python3-saml
that referenced
this issue
Oct 3, 2024
When retrieving the IDP metadata, you can now optionally specify the the capath or cafile to use for certificate verification, rather than just enabling/disabling it. This allows TLS verification of server certificates that are not in the system root store (such as when using private CAs).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Relevant code:
python3-saml/src/onelogin/saml2/idp_metadata_parser.py
Line 51 in dab5813
So it looks like the options are either:
In our situation, the government issues (intermediate) CAs from a self-signed root which is meant for private URLs (i.e. they should not be trusted by browsers/systems unless explicitly added). metadata is hosted on a URL with such a certificate. We do not want to disable SSL verification entirely, and we already have mechanisms to add this root certificate to our trust store.
Could there be an option to provide an
SSLContextinstance ourselves to be used as an optional kwarg? If you're open to this feature, then I can provide a PR.The text was updated successfully, but these errors were encountered: