Identity Console 1.8.0 - could not generate private-public key pair - docker installation

Hello,

We would like to install the Identity Console 1.8.0 using Docker.

www.netiq.com/.../deploying-identity-console-docker-container.html

We followed the installation instructions as normal, but when we start the container we only see the following entry in the 'container-startup.log':

We have copied the public key from /var/opt/novell/eDirectory/data/SSCert.pem, as we use the eDirectory CA.

We generated the .pfx file in iManager and selected the eDirectory CA as the certification authority.

The edirapi.conf file looks like this:

Note on the screenshot:
In the file actually used we also tried ospmode="false" and at origin we added a " at the end of the line.
We also checked the password for the .pfx file by importing the .pfx file in Windows once, here the private key from the server + the ROOT-CA was imported.

Normally I don't have troubles with the identity console, since there isn't much to configure. I'm pretty sure something is wrong with the certificates, but I don't know what it could be or how to debug ist.

Does anyone have experience with the installation of Identity Console 1.8.0 via Docker?

Thanks

BR

Tobias

  • 0  

    I have it running, both with docker and podman.

    I cannot see from what you have provided what is going wrong, but I do this:

    1) create container (docker create ....)

    2) copy keys.pfx and SSCert.pem as per documentation

    3) start the container (docker run ....)

    That is more or less it.

    There might be an issue with your origin="...", make sure that you only have one entry. And for edir-hosts have all your eDirectory server, both with IP and DNS.

    Otherwise look at the /config/eDirApi/var/log/edirapi.log it might give a hint. Or maybe one of the other logfiles in the same directory can.

    You can also use docker logs [-f] <container_name> to have a look at the stdout from the container startup.

  • 0   in reply to   

    Unfortunately, I only have the "container-startup.log" to choose from, it probably aborts the installation at some point before that.

    I see the following in the Docker log file:

    docker logs -f identityconsole-container-test
    Prepare Start Prerequisites
    cp: cannot stat '/config/data/SSCert.pem': No such file or directory
    cp: cannot stat '/config/data/keys.pfx': No such file or directory
    cp: cannot stat '/config/data/edirapi.conf': No such file or directory
    EULA Accepted.
    
    Configuring eDirAPI Server...
    Initializing NICI ... done.
    Initializing NICI ... done.
    set_server_mode: NICI set in server mode
    Persisting data and configurations...done
    Generating key-pairs...
    Enter PFX file password:
    ERROR: Could not generate private-public key pair.

    The only explanation I can come up with is that there is a problem with the keystore, but I don't know why. The .pfx file looks basically correct, but I may generate a new one here, or in a different way.

    I have made the adjustment in edirapi.conf, unfortunately without success.

    Thanks for your input!

  • Verified Answer

    +1  

    Ok, I'm not 100% sure if this is the solution (I need more information from the customer to verify it), but it seems that the problem was in the edirapi.conf

    With the identity console 1.8.0 and Docker version 24.0.7-ce, build 311b9ff0aa93 you have to keep the "spaces" clean in the settings.

    <Setting-Name><SPACE-Character>=<SPACE-Character>"<Setting-Value>"

    Not working example:

    listen =":9000"
    pfxpassword ="[PW]"
    bcert ="/etc/opt/novell/eDirAPI/cert/"
    ospmode ="false"
    check-origin ="false"
    loglevel ="fatal"
    origin = "https://[Server-IP]:9000"
    edir-hosts = "[Server-IP]:636,[ServerDN]:636"

    Working example:

    listen = ":9000"
    pfxpassword = "[PW]"
    bcert = "/etc/opt/novell/eDirAPI/cert/"
    ospmode = "false"
    check-origin = "false"
    loglevel = "fatal"
    origin = "https://[Server-IP]:9000"
    edir-hosts = "[Server-IP]:636,[Server-DN]:636"

    Currently the container-startup.log looks fine:

    We may still have a problem with the firewall, therefore I can't test if it really is working. If it works, I will mark this post as the solution.