I'm running a Keycloak instance in standalone mode. I have configure the Keycloak as an OIDC federated IdP in the WSO2 IS and configured the WSO2 IS as a client in the Keycloak. I also have an application running which is connected to WSO2 IS and uses Keycloak for federated authentication.
I can log into the application without any issues, but when I try to logout from the application, logout happens in the Keycloak but there's the following error in the Keycloak console,
[org.keycloak.services] (default task-17) KC-SERVICES0057: Logout for client 'WSO2-IS' failed: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I tried creating a keystore, standalone/configuration/application.keystore and importing the certificate of the WSO2 IS to it and importing the certificate of the Keycloak to WSO2 IS keystore. But it didn't work. (Note that application.keystore wasn't in the standalone/configuration/ location even after the sever was started.)
I also followed this guide to setup a keystore but nothing seems to work.
Is there something I'm missing in this setup ?
Fixed the issue after checking the certs in the truststore of the Keycloak.
Reason: cert of the WSO2 IS was not properly imported and truststore was not properly configured.
Related
I'm wondering if There is a way to force WSO2 API Manager accept untrusted certificates.
I want to use HTTPS endpoints in Publisher , And I do not want to import public certificate to client-truststore.jks and wso2carbon every time.
I also tried to set HostnameVerifier to allowAll, but still same error happens.
exception : PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I am working on WSO2 API Manager 2.1.0
Many Thanks.
You can't disable cert validation. But from 2.2.0 onwards, you can install certificates from UI.
https://docs.wso2.com/display/AM220/Dynamic+SSL+Certificate+Installation
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
The error below comes up when we stage our Bluemix Liberty app, about 1 in every 10 times. If you try and authenticate, after redirection from the OpenID provider you get a popup asking you for a username and password, which seems to have no effect. Restarting the app fixes it.
CWWKS1707E: The OpenID Connect client [NTBhZGQ4MWMtN2Y5Ni00] was
unable to create an SSL context due to [CWWKS1707E: The OpenID Connect
client [NTBhZGQ4MWMtN2Y5Ni00] was unable to create an SSL context due
to [Null ssl conext]. Ensure that your SSL feature is properly
configured.]. Ensure that your SSL feature is properly configured.
This may be related to injecting the OpenID Client configuration from a user-provided service in our server.xml:
<openidConnectClient
httpsRequired="true" id="blueid" includeIdTokenInSubject="true"
authorizationEndpointUrl="https://${cloud.services.${env.openidservice}.connection.domain}/idaas/oidc/endpoint/default/authorize"
tokenEndpointUrl="https://${cloud.services.${env.openidservice}.connection.domain}/idaas/oidc/endpoint/default/token"
issuerIdentifier="https://${cloud.services.${env.openidservice}.connection.domain}"
clientId="${cloud.services.${env.openidservice}.connection.clientid}"
clientSecret="${cloud.services.${env.openidservice}.connection.clientsecret}"
mapIdentityToRegistryUser="false" scope="openid" signatureAlgorithm="RS256"
trustAliasName="${cloud.services.${env.openidservice}.connection.certificate}"
trustStoreRef="validationKeyStore"
userIdentityToCreateSubject="uniqueSecurityName">
</openidConnectClient>
The injection must be working because the clientId mentioned in the error message is correct. Not sure why the SSL context would be null. I have tried with and without an SSL element in the server.xml, but the problem still occurs.
Does anyone know what the cause might be?
From your openid connect client configuration, you do not have SSL configuration defined for openid connect client, so openid connect client is using the server's default SSL configuration. To have a definitive behavior, I would recommend that you explicitly configure SSL for openid connect client by adding "sslRef=" into openidConnectClient, and your ssl configuration must contain a trust store that has openid provider'scertificate.
I have an application integrated with keycloak. THe application runs on wildfly server. I use web.xml to authenticate keycloak(as Login config). Apart from that i use keycloak.json file, where i define the keycloak realm settings in application.
When i invoke the application pages, the keycloak login pages opens, after entereing the credentials, it comes back to wildfly with 403 forbidden error.
Previously, the same setup was working but now after enabling ssl, i'm facing this issue.
Please help me in resolving the issue, does it require any other additional setup for ssl.
If its the case that login is failing after SSL was enabled it would be because SSL certificate was not in the truststore and you might this exception javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
For this you can disable-trust-manager , by adding the following conf in keycloak.json
{
...
"disable-trust-manager": true
}
If this solves the issue then the proper way of doing it will be to add the certificate to the trust store and specifying it in keycloak.json file like so.
{
...
"truststore": "cacerts.jks",
"truststore-password" : "password"
}
The problem was with the keycloak configuration. The roles created for my application did not have scope. after enabling the role to full scope, the issue got resolved.
As the setup worked without SSL, a scope related issue might not result in 403 error. Instead, connectivity from client application server to IDP server over the IDP HTTPS port can be tested first (can use telnet).
Else, it can be SSL certificate verification issue, as answered by #Shiva. Just to add to it, ideally, a valid CA certificate may not create trust issue. In such a case, supported browsers and java versions for your IDP certificate's CA can be checked. Just upgrading to latest java version or adding the CA's root certificate to your default trust store can solve such problems. This will not require any changes to the keycloak.json file.
GoDaddy certificate issue example.
P.S: As I could not add a comment, added these points here.
I am trying to resolve a problem whereby trying to set a users password over LDAP is failing because of an access denied error - even though I am authenticating against the AD with an admin user.
An answer found in stackoverflow says that either I have to run the IIS user as the admin user (which does work) or i should connect to LDAP via SSL.
I cant go with the first option because I am using Elastic Beanstalk which will create and terminate instances so i cant change/set the user that IIS will be running as. So I am trying to use the LDAP over SSL idea.
My question is does that still require that the client itself also have a certificate installed in order to establish trust with the Domain controller? Or does this work just by installing a cert on the Domain controller and allowing the connection over SSL?
If it requires a certificate on the client then I have the same problem as i cant install anything on the client server other than the deployed app since Beanstalk is going to recereate and terminate that instance at will.
So does LDAPS require a cert on the client?
Is there a better way to solve my problem given the infrastructure i am using?
So does LDAPS require a cert on the client?
no, LDAPS do not require client certificate. Domain controller certificate is sufficient to utilize LDAPS. More details about LDAPS and certificate requirement: LDAP over SSL (LDAPS) Certificate
trying to set a users password over LDAP is failing because of an access denied error
there might be over9000 reasons why you receive this message. You need to check whether you are successfully authenticated on DC, if yes, check whether you have permissions and privileges (especially, if UAC is enabled). I would set up audit policies (on failed user password changes) and check Security eventlog to figure out what is going wrong.
No.
For openldap, I achieved this by adding this line to ldap.conf. But be aware of that, when you do that, your connections will be open to attacks like man-in-the-middle or any other.
TLS_REQCERT never
This is what I found using trial and error approach:
Actually, LDAPS server always asks for client certificate. You can verify that by turning on SCHANNEL log and observing the following message:
If there is no client authentication certificate than LDAPS connection still succeeds, i.e. no client authentication certificate is required indeed. But if you have some invalid client authentication certificate (in my case it was an expired cert installed long ago by a third party app) the connection will fail w/o any error or warning in SCHANNEL log on the client side. It took me a while to figure this out.
Yes of corse your client need a certificate to allow ladps communication betwen
him and de server.
According to
windowsitpro.com:
As an option, you can use LDAPS for client authentication -- but doing so requires that you also install a client authentication certificate on each of your clients."