Idea ID: 2874270

Easier certificate handling

Status : New Idea

Looking at the way IC handles certificates and comparing that with the other containers for IDM it seems to differ quite a bit.

For example when it comes to the OSP or IDApps containers you keep the private/public keypair outside the container in the /data/tomcat.ks PKCS12 file.

You don't have to make changes to the files in the container itself.

While in the case of IC you have to copy files into the container, both the PKCS12 containing the private/public keypair for the webserver part and the trusted certificates.

With every upgrade of IC you must copy the files again into the new container.

Meaning you still have to keep them around outside of the container since you are going to need them again, so I don't see the point of copying certificates into the container.

1) If I want to to put a reverse proxy that terminates TLS in front of IC I should have an option to not provide IC with a PKCS12 file.

2) If I need to provide IC with a PKCS12 it should be able to live outside of the container in a mapped file or folder and IC should be able to pick it up on startup or based on an environmental variable.

3) Regarding the trusted certificates, they should also be able to live outside of the container in a volume mapped folder.

4) From a security perspective it is good that trusting a new eDirectory server requires you to copy a file to a location which means that you actually have to be an administrator on the IC server to be able to do that.

On the other hand you could just load the container on your own machine and trust any certificate you want.

From a usability standpoint, getting your hands on the eDir CA public cert its not so easy for a lot of people, they are in the business of managing users, groups, drivers etc, not in the business of trying to extract the certificate just so they can login and start working.

The way many other administration tools work is that they prompt you the first time you try to access a non-trusted TLS endpoint with the certificate details, e.g. thumbprint, serial number, validity, names etc etc. You can then decide if you want to trust it or not.

In almost all cases people click accept and that is the case with iManager itself today, many people don't change the temporary certificate to a CA-issued certificate and just click "Continue" in the browser when it prompts them during the certificate warning.

I would suggest that IC for ease of use implements something like:

A) A popup asking if the certicate should be trusted. If the user says yes IC would save the certicate for future use.


B) If "A" is to unsecure, let the administrator setting up IC point to a list of hostnames/IP-addresses of eDirectory servers using a configuration file or environmental variables and then IC would at startup automatically extract the CA certificates from those trees and save them as trusted so the administrator doesn't need to do that.


Identity Console