-
Notifications
You must be signed in to change notification settings - Fork 673
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
After upgrade from 1.18.x to 2.1 the Artifact SOAP binding fails with Empty SOAP response, check peer certificate. #1898
Comments
Update:
|
Try and figure out why certificate verification fails. Not much we can do to help you with that. |
Hi Tim, Any suggestion on how to do this? also the metadata of both SSP and the remote IDP is exactly the same and the same server SSP 1.18.4 works and 1.19.8 and 2.1.0 fail. Kind regards, |
The PHP SOAPClient uses openssl internally.
... should hopefully give you more details about the issue in the It could still very well be a bug on our end, but without understanding why the verification fails, it's really impossible for us to remotely figure this out. |
This comment was marked as outdated.
This comment was marked as outdated.
Make sure to get the values of |
The openssl verify succeeds on the server -> openssl s_client -verify 1 -host was-preprod1.digid.nl -port 443 -showcerts Server certificate issuer=C = NL, O = QuoVadis Trustlink B.V., organizationIdentifier = NTRNL-30237459, CN = QuoVadis PKIoverheid Private Services CA - G1 Acceptable client certificate CA names
|
I think you did fine with the errno/errstr.. I just wish openssl was a little bit more verbose in case of an error |
The catch seems to be in the
|
yes i can conform.. I also have added all certs to my OS trusstore, but shouldn't it also work with the line enabled icw verify depth=3? |
It does work for me if I point cafile to my entry in the trust-store. Note that the order in which the certificates are in your cafile is important! Root first, then intermediates, no cert of the actual endpoint. And note that the |
ok i'll try. with contents of: when i remove the ^M , the cert is of: |
Which is the end-certificate, not the root nor the chain.. No wonder it cannot verify |
digid.crt.txt |
yes...when i add this to the SOAPCLient is doesn't throw an error. Your digid.crt.txt was no different then mine. It's a bit unclear to me what to change in the org code of SOAPclient:
Do u suggest me to change this for now? |
Hmm, I don't really understand why the signing certificate from the metadata is being used here. I would have to consult my co-devs and see if they have a reason for this. I would argue that an HTTP-Artifact endpoint is always an HTTPS-protected endpoint that uses a different cert than the one used for signing. The HTTPS-certificate is never part of the metadata. Suit yourself to hotfix this for the shorter term. If we have to fix this library, it will take a while before it will make it into a released version of SSP |
ok Tim Clear. And thanks for all the help/support. Really appreciate it For now i have one final question, what would be the suggested hotfix? setting the verify_peer to false (which is i think a bit dangerous?) or dou have another suggestion? |
There is still lot of orgs using this software, even amongst many government orgs. I know because I'm a gov employee myself and this is my field of work. I would remove the |
thanks. Thanks for your suggestion, i will see if i can understand what u mean:) and try to change/implement this in SOAPClient |
I now have this: digid.cer is your file I now get through the soap part, but run into issues later: |
This is just a regular validation error. You must have outdated metadata from DigID. |
It (this last one) was indeed the metadata. Doesn't change the original issue here though.. Thanks and have a nice weekend! |
Specifics of your environment
SP
latest (upgrade from 1.18.x to 2.1.0)
8
SLES15
Apache
Describe the bug
A clear and concise description of what the bug is.
After upgrading to 2.1 the artifact soap binding fails with:
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Backtrace:
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 2 /var/simplesamlphp-2.1.0/src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML\Error\ExceptionHandler::customExceptionHandler)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 1 /var/simplesamlphp-2.1.0/vendor/symfony/error-handler/ErrorHandler.php:541 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 0 [builtin] (N/A)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Caused by: Exception: Empty SOAP response, check peer certificate.
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Backtrace:
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 7 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/SOAPClient.php:147 (SAML2\SOAPClient::send)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 6 /var/simplesamlphp-2.1.0/vendor/simplesamlphp/saml2/src/SAML2/HTTPArtifact.php:152 (SAML2\HTTPArtifact::receive)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 5 /var/simplesamlphp-2.1.0/modules/saml/src/Controller/ServiceProvider.php:203 (SimpleSAML\Module\saml\Controller\ServiceProvider::assertionConsumerService)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 4 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:163 (Symfony\Component\HttpKernel\HttpKernel::handleRaw)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 3 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/HttpKernel.php:75 (Symfony\Component\HttpKernel\HttpKernel::handle)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 2 /var/simplesamlphp-2.1.0/vendor/symfony/http-kernel/Kernel.php:202 (Symfony\Component\HttpKernel\Kernel::handle)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 1 /var/simplesamlphp-2.1.0/src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] 0 /var/simplesamlphp-2.1.0/public/module.php:17 (N/A)
%b %16 %12:%Nov:%th simplesamlphp ERROR [047aa951e5] Error report with id 43c3ae5b generated.
After authenticating at the IdP (DigiD)
When i change verify_peer in the vendor/simplesamlphp/saml2/src/SAML2/SOAPClient.php from true -> false it works:
// create ssl context
$ctxOpts['ssl']['verify_peer'] = true;
$ctxOpts['ssl']['verify_depth'] = 1;
$ctxOpts['ssl']['cafile'] = $peerCertFile;
to
// create ssl context
$ctxOpts['ssl']['verify_peer'] = false;
$ctxOpts['ssl']['verify_depth'] = 1;
Expected behavior
Working when verify_peer is still true like in 1.18.x (i am testing lates 1.19 version also.
Unrelated noise
**Additional context** it for DigiD -> https://www.logius.nl/domeinen/toegang/digid/documentatie/koppelvlakspecificatie-digid-saml-authenticatie it states (in dutch): Gebruikte profiles van SAML Een SAML profile is een specifieke set regels die gebruikt wordt voor een bepaalde use case. DigiD gebruikt twee profiles van de SAML-standaard, te weten:Webbrowser SSO profile, met een HTTP Redirect of HTTP Post binding voor het front channel verkeer, en een HTTP Artifact binding voor het back channel verkeer. (Het front channel is de communicatie tussen de dienstaanbieder en DigiD via de browser van de eindgebruiker. Het back channel is de directe communicatie tussen de dienstaanbieder en DigiD).
Single Logout profile, issued by Session Participant to Identity Provider. Een gedetailleerde uitleg van dit profiel is te vinden in de SAML profiles zoals genoemd onder hoofdstuk Gerelateerde pagina's.
Gebruikte bindings
De DigiD SAML-implementatie maakt gebruik van de volgende bindings:
SP Initiated: HTTP Redirect binding (Location HTTP header contains SAMLRequest AuthnRequest).
SP Initiated: HTTP Post binding (HTML form contains SAMLRequest AuthnRequest).
SP Initiated: HTTP Artifact binding (SOAP Artifact Resolve & Artifact Response) t.b.v. het back channel verkeer (de directe communicatie tussen de dienstaanbieder en DigiD).
Let op: Uit veiligheidsoverwegingen ondersteunt DigiD geen authenticatie Response over een POST binding. Gebruik altijd de HTTP-Artifact binding.
So the Artifact binding is mandatory for this IdP..
The text was updated successfully, but these errors were encountered: