I built an Apereo CAS demo server with a WAR overlay (with which
different services should be authenticated).
I have set up delegated authentication with SAML2 (for integrating
with italian SPID system), following this guide
https://apereo.github.io/2019/02/25/cas61-delegate-authn-saml2-idp/
I copied the SP metadata to a IDP configuration.
This IDP is a test IDP instance, meant to check if SP metadata and the SAML request are ok.
When I run the server and I browse it,
I can see the second login form, but when I click it, the validation checks shows some errors.
Among them there is the following:
"The certificate must be signed with a valid algorithm."
"The certificate must not be signed using the SHA1 algorithm (deprecated)."
I am pretty sure that SHA-256 would be fine with the IDP validator.
In the documentation
https://apereo.github.io/cas/development/integration/Delegate-Authentication-SAML.html
I see that the following parameter should be in charge of specifying
the signing certificate algorithm:
cas.authn.pac4j.saml[].signature-algorithms:
Its description is
# Required: false
# Type: java.util.List<String>
# Owner: org.apereo.cas.configuration.model.support.pac4j.saml.Pac4jSamlClientProperties
# Module: cas-server-support-pac4j-webflow
# Collection of signing signature algorithms, if any, to override the global defaults.
# cas.authn.pac4j.saml[].signature-algorithms:
I don't know what values are allowed there. I googled a lot but with no luck.
I have tried to set that list like this
cas.authn.pac4j.saml[0].signature-algorithms=["sha256WithRSAEncryption"],
cas.authn.pac4j.saml[0].signature-algorithms=["SHA256withRSA"] but,
after clicking the SAML login button, I always get the following
error:
org.pac4j.saml.exceptions.SAMLException: org.pac4j.saml.exceptions.SAMLException: Could not determine the signature parameters
at org.pac4j.saml.crypto.DefaultSignatureSigningParametersProvider.build(DefaultSignatureSigningParametersProvider.java:60)
...
How can I specify a SHA-256 algorithm for signing the certificate?
Related
I am getting success and responder status information too from ADFS, I checked for both of cases by turning on and off validate signature switch, setting PROXY_ADDRESS_FORWARDING=true and also to porto HTTP and https forwarding.
No one solution from above given worked well for me.
• You can try the settings in keycloak to be configured as below for it to act as a service provider to ADFS IdP so that you will be able to get the SAML requests to process correctly: -
‘ IdP URL: ${IDP_URL}/adfs/ls/
NameID Policy Format: persistent
WantAuthnRequestsSigned: true
WantAssertionsSigned: true
SignatureAlgorithm: RSA_SHA256
SAMLSignatureKeyName: CERT_SUBJECT ‘
Thus, when you configure the above settings in keycloak, also ensure that you update NameID policy in keycloak as SP and similarly custom settings on the IdP side as well to ensure NameID is sent back as ‘persistent’ in format.
Had the same error message with a misconfigured identity provider on Keycloak 15.
Try this:
Go to https://[ADFS server hostname]/federationmetadata/2007-06/federationmetadata.xml to download the ADFS server metadata
Find the X509Certificate fields marked 'signing' in the metadata
Go to your Keycloak Identity Provider definition -> settings -> 'Validating X509 Certificates' and insert the values from the metadata. Alternatively you can import the metadata file using Keycloak's import button when you create a new identity provider. Note: if the metadata contains multiple certificate values you can comma delimit them when you enter them in your keycloak identity provider definition.
Could you please let me know how I can change the Resident metadata value to have a different certificate other than ws02 where I have signed a metadata using a specific cert. Seems IS is signing the SAMLRequest using its own cert so i get an invalid signature when sending a SAML Request to the Identity Provider.
I change the certificate alias on service provider configuration from IS console to the appropriate certificate but doesn't seem to overwrite signing it and still using the standard wso2 certificate.
Is there somewhere in the IS configuration where I can change the wso2carbon cert to one of my own so it will apply to identity provider resident?
Currently, the primary keystore configured by the / element in the /repository/conf/carbon.xml file is used for internal data encryption (encrypting data in internal data stores and configuration files) as well as for signing messages that are communicated with external parties. However, it is sometimes a common requirement to have separate keystores for communicating messages with external parties (such SAML, OIDC id_token signing) and for encrypting information in internal data stores. This is because, for the first scenario of signing messages, the keystore certificates need to be frequently renewed. However, for encrypting information in internal data stores, the keystore certificates should not be changed frequently because the data that is already encrypted will become unusable every time the certificate changes.
This feature will be available from IS 5.5.0 WUM and above. You can follow steps in [1] to configure multiple keystores.
<InternalKeyStore>
<Location>${carbon.home}/repository/resources/security/internal.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyAlias>wso2carbon</KeyAlias>
<KeyPassword>wso2carbon</KeyPassword>
</InternalKeyStore>
[1]https://docs.wso2.com/display/ADMIN44x/Configuring+Keystores+in+WSO2+Products#ConfiguringKeystoresinWSO2Products-second_keystore_internal_dataConfiguringaseparatekeystoreforencryptingdataininternaldatastores
Being stuck with signing (Authenticode) using PKCS#11 tokens, and given the amazingly poor driver support from the vendor (SafeNet), we're signing Windows code on Linux.
All of this is working fine using all of our tokens on several build servers. However, I have one token that fails, depending on the mechanism being used. From Java, using Jsign and the SunPKCS11 provider, everything works fine with this token.
However, from osslsigncode, signing fails with this token:
Unable to enumerate certificates
PKCS11_get_private_key returned NULL
Failed to load private key 9df65894eb084ba3140555614123992:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:124:
Failed
The difference between the working token and the non-working token is that the non-working token includes not just the certificate, but also its trust chain:
# pkcs11-tool --module libeToken.so --list-objects
Using slot 0 with a present token (0x0)
Certificate Object, type = X.509 cert
label: te-69f298db-2f32-4a94-82ea-3e11829b26cd
ID: 9df65894eb084ba3
Certificate Object, type = X.509 cert
label:
Certificate Object, type = X.509 cert
label:
Using p11tool, the two empty-looking certs above show as:
Type: X.509 Certificate
Label:
Flags: CKA_CERTIFICATE_CATEGORY=CA;
ID:
My other tokens, all of which work fine, do not include these CA certs. This token was created recently, so it may be that either the token firmware is different from my others, or the token installation process has changed since I created the other, working tokens. The certificate is the same on all of them, working and non-working.
I've confirmed (via gdb) that the correct key ID is being passed into ENGINE_load_private_key.
I'm not sure who owns the ENGINE API in this case - is it a token driver issue? (SafeNet) Is it a problem with OpenSC? etc. It would be helpful to find some other tool that uses the API in the same way so I could confirm whether the problem somehow lies with osslsigncode (which isn't actively supported) or one of the lower layers in this tower of cards.
P.S. I used PKCS#11 Spy, and it shows enumeration of all of the certs in the chain, so it's finding the key pair (by ID), but then fails - no errors in PKCS#11 Spy - all CKR_OK.
P.P.S. To address the question of whether this token also has a private key...
Using slot 0 with a present token (0x0)
Logging in to "Code Signing Token 11".
Please enter User PIN:
Private Key Object; RSA
label:
ID: 9df65894eb084ba3
Usage: decrypt, sign, unwrap
Certificate Object, type = X.509 cert
label: te-69f298db-2f32-4a94-82ea-3e11829b26cd
ID: 9df65894eb084ba3
Certificate Object, type = X.509 cert
label:
Certificate Object, type = X.509 cert
label:
The solution, at least for now, seems to be just deleting the CA certs from the token (via SAC Tools on Windows). Once done, osslsigncode (via the PKCS#11 stack) has no problem finding the token. The CA certs aren't needed for signing, so deleting them presents no problem.
It seems that you did NOT login to the token. In pkcs11-tool, use --login --pin <your-pin-code> if you want to retrieve private objects.
It should be noted that the signing process needs an appropriate private key (not certificate).
I have a perfectly working Spring Security web application that uses SAML SSO. The client (IdP) changed their certs. I updated the cert and the CA certs to my keystore.jks. I am getting redirected properly to the IdP, I log in and get properly redirected back to my app. At that point I am getting theses in the logs:
Attempting to validate signature using key from supplied credential (validate) (SignatureValidator.java:54)
Creating XMLSignature object (buildSignature) (SignatureValidator.java:90)
Validating signature with signature algorithm URI: http://www.w3.org/2000/09/xmldsig#rsa-sha1 (validate) (SignatureValidator.java:64)
Validation credential key algorithm 'RSA', key instance class 'sun.security.rsa.RSAPublicKeyImpl' (validate) (SignatureValidator.java:65)
Signature validated with key from supplied credential (validate) (SignatureValidator.java:70)
SSL negotiation with xxxxxx using candidate credential was successful (verifySignature) (BaseSignatureTrustEngine.java:148)
Successfully verifiServer certificate verify failed: signer not foundidate) (BaseSignatureTrustEngine.java:101)
Attempting to establish trust of KeyInfo-derived credential (validateConnected to HTTPS on 34.196.133.252)
Failed to validate untrusted credential against trusted key (validate) (ExplicitKeyTrustEvaluator.java:95
org.opensaml.xml.validation.ValidationException: Signature did not validate against the credential's key
So it looks like something is being validated, but I do not understand why it's failing. I double checked with keytool and all the CA's are there.
I'm using the SignedXml.CheckSignature(X509Certificate2, boolean) method. I would like to know what checks are performed when deciding the validity of the certificate. I have verified that the Current User/Not Trusted list is checked. The documentation says it will use the "address book" store, searching by subject key identifier, to build the certificate chain. I imagine this means the Local Machine and Current User certificate stores?
Am I right to think that certificate revocation and signature timestamp are not checked? To do an OCSP check for certificate revocation, am I obliged to use Bouncy Castle?
In the remarks in the msdn article you link to one finds:
In version 1.1 of the .NET Framework, the X.509 certificate is not verified.
In version 2.0 and later, the X.509 certificate is verified.
In version 2.0 and later of the .NET Framework, the CheckSignature method will search the "AddressBook" store for certificates suitable for the verification. For example, if the certificate is referenced by a Subject Key Identifier (SKI), the CheckSignature method will select certificates with this SKI and try them one after another until it can verify the certificate.
Thus, first of all the behavior of that method has changed in different .NET framework versions. So for reproducible results, you had better not count on that method even check the certificate at all.
Furthermore, the formulation try them one after another until it can verify the certificate sounds like there just might be the mathematical test whether or not the certificate is signed by its alleged issuer.
https://referencesource.microsoft.com/#System.Security/system/security/cryptography/xml/signedxml.cs,b9518cc2212419a2
It checks
The certificate has no Key Usage extension, or the Key Usage extension has either Digital Signature or Non Repudiation usages enabled
The certificate chains up to a trusted root authority
The certificate has not been revoked
The certificate was not expired when you called this method
It doesn't know when the document was signed, so it doesn't answer that question.
That none of the certificates in the chain are explicitly prohibited by the user or system configuration.