Curity Setup | SSL Certificates are invalid - Exception - Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:

I am new to Curity server, trying to setup community edition (on AZure) as openId based provider. The SSL certificates generated with Curity admin are shown invalid while accessing the instance. I have tried generating the new SSL certificate as well with all the information need, however the certificates are still shown invalid.

My question(s) -

1. What is the correct way to setup SSL certificates so that they are valid
2. I have wild card certificates, how can those be reused here.
3. Can i disable HTTPS on Curity and have a proxy server take care of HTTPS and forward request to Curity

I looked at the solution/script suggested in Stackoverflow question, however the Azure container doesn't let me setup certbot and run this script (I don't have root access).

1. Generate new SSLs providing all the information needed in the form (in Curity Admin UI)
2. I have tried uploading certificate chain from admin ui however its not accepting the certificates and error out with different messages (missing type or missing valid date)
3. Disabled https and used NGINX as proxy but the cookies are lost and it shows invalid request
   

EXTERNAL AND INTERNAL URLs

In deployed setups the external URL is usually different to the physical URL of the server or container:

• The external runtime URL might be https://login.example.com
• The internal runtime URL might be http://idsvrhost:8443

SSL WITH A REVERSE PROXY

If hosting the Curity Identity Server behind a reverse proxy, eg NGINX, the SSL certificate will be configured there. In this case, disable HTTPS in the Admin UI, under system / deployment / service role. Then configure the external URL under system / general / base URL.

At this point you should be able to navigate to https://login.example.com, without errors, as long as the SSL certificate is issued by a trusted authority.

If you browse to the OpenID Connect metadata endpoint, you will then get valid internet URLs for clients, eg for the authorization and token endpoints. These must use the external URL - doing so will fix your redirect issues.

SSL WITHOUT A REVERSE PROXY

If you are not using a reverse proxy, the simplest option is to just import a password protected certificate and key file, eg in the PKCS#12 format. You can do this using the facilities menu of the admin UI, and navigating to Keys and crpytography / TLS / Server SSL Keys / +.

You then need to ensure that HTTPS and this keystore are selected under system / deployment / service role. Again you need to configure a base URL that will result in valid OAuth endpoints for internet clients.

ADMIN URLs

The process if you also want to expose the admin UI is equivalent, where you may have these URLs. You can set the external admin base URL under system / admin service / base URL, and follow similar steps.

• The external admin URL might be https://admin.example.com
• The internal admin URL might be http://idsvrhost:6749

FURTHER INFO

The generated SSL certificates are just a convenience for developers when getting started. You are meant to replace them with real certificates for deployed systems. For more about how this works, see this configuration management tutorial, which will guide you through the technical options.