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.
Related
I'm having a .net core API and an EmailService as a connected service (WCF)
The EmailService is hosted on IIS (HTTPS); I'm trying to connect to the emailService with a Client Certificate. Everything is fine but i'm getting the
The HTTP request was forbidden with client authentication scheme 'Anonymous' error;
On the EmailService side:
The SSL Settings are on Require SSL (Require), the IIS Binding is on HTTPS
On the API side:
When i'm trying to access the emailservice by chrome browser, i'm getting a prompt for a client certificate, i'm picking the cert and everything works alright;
Any suggestions?
Thanks
I am not sure if you can call the service properly since WS-security is not supported in DotNet Core. Anyway, this error typically indicates that the client’s certificate cannot be recognized by the server-side when establishing the Https communication. Also, if your client communicates with the server over HTTP and the server requires SSL, this kind of error also occurred.
The Https secure communication between the client-side and the server-side can not be established properly. As you know, the https secure communication requires the procedure of exchanging each other’s public key of the certificate. Therefore, the server-side and the client-side should establish mutual trust. In other words, the server’s certificate must be trusted by the client and the client’s certificate must be trusted by the server. The specific operation is to install the certificate in the local Trusted Root Certification Authorities.
Please refer to the below link.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/transport-security-with-certificate-authentication
Besides, the client-side should have access to the private key of the certificate provided by the client so that the https secure communication is valid. The specific operation is to add the current user to the private key management group of the certificate.
Feel free to let me know if there is anything I can help with.
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 having an issue where service calls that I am making cannot validate server certificates presented by the TMG as part of connecting to the service. The certificate URLS from the TMG address are not reachable from the target servers. This is causing 30 second timeouts for new connections.
Is there a way to disable certificate revocation checks in Mule to avoid this issue?
If you're talking about Mule HTTP endpoints, then this would vary, if you're using http transport you can create a custom message dispatcher and allow http client to ignore the certificates, otherwise you can manually install the certificates in the keystore so you don't get SSL errors.
I have setup IBM MobileFirst 7.0 with IBM HTTPServer. HTTPServer only listens for SSL traffic on 443 (no requests over http on port 80 are being processed). The plugin-cfg.xml is directing the /appcenterconsole URLs to the WebSphere Liberty server running the MobileFirst app.
At first, the App Center console loaded and I could login, but any calls to /appcenterconsole/services/* were getting a certificate chain error. I fixed this by adding the http server's certificate to the Liberty keystore. After executing this change, the behavior changed such that on login to App Center, the user immediately receives a 'Your session has expired' message and is sent back to the login page.
Why is my session getting lost? The HTTP server has a JSESIONID for requests to /appcenterconsole/*.
Can the HTTP plugin send the traffic over http to the Liberty server to avoid the SSL chain issue?
This looks like an SSO (Single Sign On) problem. There are two web application, AppCenterConsole and AppCenterServices, and both require authentication, hence they should be set up with SSO. It seems you reach the AppCenterConsole but not the AppCenterService.
Liberty has SSO by default, but if you are using multiple servers, ensure that you have followed the instructions Configuring LTPA on the Liberty profile in the Websphere Liberty Profile documentation.
Alternatively, you can set the JNDI property ibm.appcenter.ui.cors to false for the AppCenterConsole. This will avoid the redirection of requests from the AppCenterConsole to the AppCenterService. If it doesn't already fix the problem, then at least it will produce a better error message with a stack trace that points to the real problem.
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."