Skip to content
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

Open
msc1978 opened this issue Nov 17, 2023 · 22 comments

Comments

@msc1978
Copy link

msc1978 commented Nov 17, 2023

Specifics of your environment

  1. Are you acting as SP/IdP/proxy?
    SP
  2. SimpleSAMLphp: What version are you using?
    latest (upgrade from 1.18.x to 2.1.0)
  3. PHP: What version are you using?
    8
  4. Platform: unix or Windows?
    SLES15
  5. Webserver: Apache/Nginx/ISS?
    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..

@msc1978
Copy link
Author

msc1978 commented Nov 17, 2023

Update:

  • just tested with 1.19.8 with both php7 and php8 -> fails the same as 2.1.0 (also here verifypeer -> false makes it work)
  • simplesamlphp-1.18.4 with php 7 works

@tvdijen
Copy link
Member

tvdijen commented Nov 17, 2023

Try and figure out why certificate verification fails. Not much we can do to help you with that.

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

Hi Tim,

Any suggestion on how to do this?
since i tried to validate all certs with openssl, eg:
openssl s_client -host xxxx -port 443 -showcerts
they all validate correctly

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.
So wouldn't that mean the certs are all ok?

Kind regards,
Maarten

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

The PHP SOAPClient uses openssl internally.
Replacing the call with something like ...

$fp = stream_socket_client('ssl://your-digid-endpoint:443', $errno, $errstr, 30, STREAM_CLIENT_CONNECT, $context);

... should hopefully give you more details about the issue in the $errno/$errstr ..

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.

@msc1978

This comment was marked as outdated.

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

Make sure to get the values of $errstr and $errno too, because this doesn't tell us anything we didn't already know.
You can also try openssl s_client -host <your-digid-host> -port <the-port> -showcerts -v from the command-line of your server. It should be a little more verbose when it comes to error messages

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

The openssl verify succeeds on the server -> openssl s_client -verify 1 -host was-preprod1.digid.nl -port 443 -showcerts
output

Server certificate
subject=C = NL, O = Logius, serialNumber = 00000004166909913000, CN = was-preprod1.digid.nl

issuer=C = NL, O = QuoVadis Trustlink B.V., organizationIdentifier = NTRNL-30237459, CN = QuoVadis PKIoverheid Private Services CA - G1


Acceptable client certificate CA names
C = NL, O = Staat der Nederlanden, CN = Staat der Nederlanden Private Root CA - G1
C = NL, O = Staat der Nederlanden, CN = Staat der Nederlanden Private Services CA - G1
C = NL, O = KPN B.V., CN = KPN PKIoverheid Private Services CA - G1
C = NL, O = QuoVadis Trustlink B.V., organizationIdentifier = NTRNL-30237459, CN = QuoVadis PKIoverheid Private Services CA - G1
C = NL, O = Digidentity B.V., organizationIdentifier = NTRNL-27322631, CN = Digidentity BV PKIoverheid Private Services CA - G1
C = NL, O = CIBG, organizationIdentifier = NTRNL-50000535, CN = UZI-register Private Server CA G1
C = NL, O = CIBG, organizationIdentifier = NTRNL-50000535, CN = ZOVAR Private Server CA G1
C = RO, O = certSIGN, OU = certSIGN Enterprise CA Class 3 G2, CN = certSIGN Enterprise CA Class 3 G2
C = RO, O = certSIGN, OU = certSIGN ROOT CA
C = NL, O = QuoVadis Trustlink B.V., CN = QuoVadis Europe SSL CA G2
C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 G3
Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:RSA+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:RSA+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits

SSL handshake has read 8439 bytes and written 425 bytes
Verification: OK

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

also add the logs of the errno and errstr in 1.19.8 -> adds these 2 log lines
Nov 18 13:47:36 simplesamlphp ERROR [505d504ff8] msc $errno 0
Nov 18 13:47:36 simplesamlphp ERROR [505d504ff8] msc $errstr

for 1.18.4 it logs:
Nov 18 13:44:27 simplesamlphp ERROR [ed3cba9cd9] msc $errno 0
Nov 18 13:44:27 simplesamlphp ERROR [ed3cba9cd9] msc $errstr

maybe i am logging it wrong? this is what is did (SSP 1.19.8):
$fp = stream_socket_client('ssl://was-preprod1.digid.nl:443', $errno, $errstr, 30, STREAM_CLIENT_CONNECT, $context);
$container->getLogger()->error('msc $errno ' . $errno);
$container->getLogger()->error('msc $errstr ' . $errstr);

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

I think you did fine with the errno/errstr.. I just wish openssl was a little bit more verbose in case of an error

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

The catch seems to be in the verify_depth.. If I change this to 3 or higher, it validates.
My proof-of-concept code:

<?php

$ctxOpts = [];
$ctxOpts['ssl']['verify_peer'] = true;
$ctxOpts['ssl']['verify_depth'] = 3;
//$ctxOpts['ssl']['cafile'] = $peerCertFile; // I have added the chain to my OS's trust store

$context = stream_context_create($ctxOpts);

$fp = stream_socket_client('ssl://was-preprod1.digid.nl:443', $errno, $errstr, 30, STREAM_CLIENT_CONNECT, $context);

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

yes i can conform..
but i have to disable this line (like u did): //$ctxOpts['ssl']['cafile'] = $peerCertFile; // I have added the chain to my OS's trust store

I also have added all certs to my OS trusstore, but shouldn't it also work with the line enabled icw verify depth=3?

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

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 openssl command displays them in the reverse order.
It still doesn't explain why this breaks in between SSP-versions.. I would have expected this to be related to OpenSSL v1.1 vs. v3.0 or something

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

ok i'll try.
But i logged the peercertfile, it showed:
/tmp/simplesaml/414d0e3f2f6f1da7be4a72e03074bf0035e80ff2.pem

with contents of:
-----BEGIN CERTIFICATE-----
MIIGgDCCBGigAwIBAgIUeaJCHN5WYpAYm3Ob95K++wuUKF4wDQYJKoZIhvcNAQEL^M
BQAwUzELMAkGA1UEBhMCTkwxETAPBgNVBAoMCEtQTiBCLlYuMTEwLwYDVQQDDChL^M
UE4gUEtJb3ZlcmhlaWQgUHJpdmF0ZSBTZXJ2aWNlcyBDQSAtIEcxMB4XDTIwMTEw^M
NDE1MDUxMFoXDTIzMTEwNDE1MDUxMFowgYYxCzAJBgNVBAYTAk5MMREwDwYDVQQH^M
DAhEZW4gSGFhZzEPMA0GA1UECgwGTG9naXVzMRMwEQYDVQQLDApBZmQuIERpZ2lE^M
MR0wGwYDVQQFExQwMDAwMDAwNDE2NjkwOTkxMzAwMDEfMB0GA1UEAwwWc2FtbC1z^M
aWduLnBwMS5kaWdpZC5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB^M
AMj8kKdoo1t07NFi+DMP+84EoRg9skqfoiApb+8IwRIpVjeCu6tY9Yso/Jc9lmPl^M
zLdRDKTOjKc7/taswCLv1k+iUvNah5y0Mh3MDoTWp3+QcUqim0eLn6dUMNyMqP0M^M
QLqIXThzETU5FynbbTv27vxWtqJdWPilv9E9+N19+vpRMgbiZ5mIarfhAuveii1+^M
mGA9YZF2jMsDmfanJ4L0pL4MJR44FCbs2ce1n96YNhZiZ1Xht5Y46jXXvpQkHFxW^M
DbAGakkmnCi8z9D0BBEYQ2MceYz2dBwqwDtYFgWq89XfMXOk8NZ7r65xu9GJ56O2^M
v3lcHqvwDPXfgzYV1gX6pr0CAwEAAaOCAhYwggISMAwGA1UdEwEB/wQCMAAwHwYD^M
VR0jBBgwFoAUuNRMn6hbbtolp2iO74xGGv4fU2UwOAYIKwYBBQUHAQEELDAqMCgG^M
CCsGAQUFBzABhhxodHRwOi8vcHJvY3NwLm1hbmFnZWRwa2kuY29tMCEGA1UdEQQa^M
MBiCFnNhbWwtc2lnbi5wcDEuZGlnaWQubmwwgdcGA1UdIASBzzCBzDCByQYKYIQQ^M
AYdrAQIIBjCBujBCBggrBgEFBQcCARY2aHR0cHM6Ly9jZXJ0aWZpY2FhdC5rcG4u^M
Y29tL2VsZWt0cm9uaXNjaGUtb3BzbGFncGxhYXRzMHQGCCsGAQUFBwICMGgMZk9w^M
IGRpdCBjZXJ0aWZpY2FhdCBpcyBoZXQgQ1BTIFBLSW92ZXJoZWlkIFByaXZhdGUg^M
U2VydmljZXMgU2VydmVyIGNlcnRpZmljYXRlbiB2YW4gS1BOIHZhbiB0b2VwYXNz^M
aW5nLjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwXAYDVR0fBFUwUzBR^M
oE+gTYZLaHR0cDovL2NybC5tYW5hZ2VkcGtpLmNvbS9LUE5CVlBLSW92ZXJoZWlk^M
UHJpdmF0ZVNlcnZpY2VzQ0FHMS9MYXRlc3RDUkwuY3JsMB0GA1UdDgQWBBSdgnpr^M
zvDHfAbX9iI6dbAjPVlZNjAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQAD^M
ggIBABsXIARBHjAnx5u8S1Wc7rmt18lzdvd1BdQRogSmCv2rVoRryJvKs3j2XaFJ^M
FLvz/JaHI1vThna31/2xjGlITG8e1Xx4pDftXYpumbWpRq3UAV+ZcvP8Ua1vLYON^M
1RY+a9EmaQA8ITXOK3av5RMnv3uDoHtCdBvsBOCZmZaWTDf4gn8jXWiryalkweGE^M
erb01QpaOa2wBc6rTenVHA9GK8Rb1CKVneq8pJdS8Na7WFBjU1Zzq28Lor4dERJX^M
TG5QKTNWC4B58stokDiogwkVhjb27Uy0sCJn5wN97OmUR2YbQHFJ9dm/kpNF+Pv3^M
KQzAr4FBLf1F332ZUUExh9LhwPdmjQr8vHpP5cLf6WHsEFAZj7s7SLMn+rl9vXzu^M
MKUp0EauB5cB1TPwnrUJE3BoKzi/FUF23TGoTWfqjlVfgCeGc2/RRcpZUlrLSgpf^M
DpE5p2NImUJ6jqPsm4/tLYG6gP1cGD3rNlEZxEuFeOFHx/gOUTcCDxcgNdolrfD+^M
efWpdq+ZMRugvi5Edj1QADa4d4ehrwx/EIQAAghaqlJNsvKxG/1BryrlzDrJ3xrV^M
uXTJEWfq3Ea+M13dEDXvnc5nhQt7gPY0S0ybzB/MHlmjBfFLfXq+euhQtIZDK4bW^M
hNknB91MyNInX/LC2NywV47TPfltF9MnqOa+XuExXCXhta+D^M
-----END CERTIFICATE-----

when i remove the ^M , the cert is of:
Certificate Information:
Common Name: saml-sign.pp1.digid.nl
Subject Alternative Names: saml-sign.pp1.digid.nl
Organization: Logius
Organization Unit: Afd. DigiD
Locality: Den Haag
State:
Country: NL
Valid From: November 4, 2020
Valid To: November 4, 2023
Issuer: KPN PKIoverheid Private Services CA - G1, KPN B.V.
Key Size: 2048 bit
Serial Number: 79a2421cde566290189b739bf792befb0b94285e

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

Which is the end-certificate, not the root nor the chain.. No wonder it cannot verify

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

digid.crt.txt
This should work for you

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

yes...when i add this to the SOAPCLient is doesn't throw an error. Your digid.crt.txt was no different then mine.
for swithcing between SSP versions i just change the symlink of the SSP dir.

It's a bit unclear to me what to change in the org code of SOAPclient:
// do peer certificate verification
if ($dstMetadata !== null) {
$peerPublicKeys = $dstMetadata->getPublicKeys('signing', true);
$certData = '';
foreach ($peerPublicKeys as $key) {
if ($key['type'] !== 'X509Certificate') {
continue;
}
$certData .= "-----BEGIN CERTIFICATE-----\n".
chunk_split($key['X509Certificate'], 64).
"-----END CERTIFICATE-----\n";
}
$peerCertFile = $container->getTempDir().'/'.sha1($certData).'.pem';
if (!file_exists($peerCertFile)) {
$container->writeFile($peerCertFile, $certData);
}
// create ssl context
$ctxOpts['ssl']['verify_peer'] = true;
$ctxOpts['ssl']['verify_depth'] = 3;
$ctxOpts['ssl']['cafile'] = $peerCertFile;

    }

Do u suggest me to change this for now?

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

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.
Allowing you to configure a CA-file and dropping the verify_depth would solve the issue and makes a lot more sense to me.

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

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

ok Tim Clear. And thanks for all the help/support. Really appreciate it
I know there are a lot of orgs using SSP for DigID in the NL a few years ago. Don;t know how that is currently.

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?

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

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 verify_depth and hardcode cafile to the certificate-chain file. This is safe and should remain functional even if Logius rolls over their certificate.

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

thanks.
To be clear, my question was not meant as a doubt of the widely usage of SSP, but more that probably more orgs using DigiD with SSP will encounter this in the near future:) I know SSP is used a lot.

Thanks for your suggestion, i will see if i can understand what u mean:) and try to change/implement this in SOAPClient

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

I now have this:
// create ssl context
$ctxOpts['ssl']['verify_peer'] = true;
//$ctxOpts['ssl']['verify_depth'] = 1;
//$ctxOpts['ssl']['cafile'] = $peerCertFile;
$ctxOpts['ssl']['cafile'] = "/tmp/digid.cer";

digid.cer is your file

I now get through the soap part, but run into issues later:
:09 simplesamlphp DEBUG [afbf9c79c0] </soapenv:Envelope>
Nov 18 16:32:09 simplesamlphp DEBUG [afbf9c79c0] Valid ArtifactResponse received from IdP
Nov 18 16:32:09 simplesamlphp DEBUG [afbf9c79c0] Loading state: '_46c7ffc2649c962bff6be254a8c22ca151d5c5bb81'
Nov 18 16:32:09 simplesamlphp DEBUG [afbf9c79c0] Received SAML2 Response from 'https://was-preprod1.digid.nl/saml/idp/metadata'.
Nov 18 16:32:09 simplesamlphp DEBUG [afbf9c79c0] Has 1 candidate keys for validation.
Nov 18 16:32:09 simplesamlphp DEBUG [afbf9c79c0] Validation with key #0 failed with exception: Unable to validate Signature
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] Backtrace:
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 1 /var/simplesamlphp-1.19.8/www/_include.php:17 (SimpleSAML_exception_handler)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 0 [builtin] (N/A)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] Caused by: Exception: Unable to validate Signature
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] Backtrace:
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 10 /var/simplesamlphp-1.19.8/vendor/simplesamlphp/saml2/src/SAML2/Utils.php:196 (SAML2\Utils::validateSignature)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 9 [builtin] (call_user_func)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 8 /var/simplesamlphp-1.19.8/vendor/simplesamlphp/saml2/src/SAML2/Message.php:263 (SAML2\Message::validate)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 7 /var/simplesamlphp-1.19.8/vendor/simplesamlphp/saml2/src/SAML2/HTTPArtifact.php:195 (SAML2\HTTPArtifact::validateSignature)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 6 [builtin] (call_user_func)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 5 /var/simplesamlphp-1.19.8/vendor/simplesamlphp/saml2/src/SAML2/Message.php:263 (SAML2\Message::validate)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 4 /var/simplesamlphp-1.19.8/modules/saml/lib/Message.php:230 (SimpleSAML\Module\saml\Message::checkSign)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 3 /var/simplesamlphp-1.19.8/modules/saml/lib/Message.php:646 (SimpleSAML\Module\saml\Message::processResponse)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 2 /var/simplesamlphp-1.19.8/modules/saml/www/sp/saml2-acs.php:141 (require)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 1 /var/simplesamlphp-1.19.8/lib/SimpleSAML/Module.php:266 (SimpleSAML\Module::process)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] 0 /var/simplesamlphp-1.19.8/www/module.php:10 (N/A)
Nov 18 16:32:09 simplesamlphp ERROR [afbf9c79c0] Error report with id f1262e7f generated.

@tvdijen
Copy link
Member

tvdijen commented Nov 18, 2023

This is just a regular validation error. You must have outdated metadata from DigID.

@msc1978
Copy link
Author

msc1978 commented Nov 18, 2023

It (this last one) was indeed the metadata. Doesn't change the original issue here though..
but the "hotfix" u suggested works for that one.

Thanks and have a nice weekend!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants