Re: [HTCondor-users] significance of certificate common name(CN)

[Jaime Frey <jfrey@xxxxxxxxxxx>]

The SSL authentication method assumes server sideâs SSL certificate will have a CN value that matches its hostname. This is not true with your certificate, where the CN value is â My cluster olac2â. As a result, the client is rejecting the serverâs certificate.

You can disable this check of the CN value by setting SSL_SKIP_HOST_CHECK=false in your configuration files. This is not ideal, as the client will then trust any certificate signed by a CA that HTCondor is configured to trust. By default, this includes all of the standard CAs that come with a linux installation (in /etc/pki/tls/certs/ca-bundle.crt).

Alternatively, you can create a new certificate whose CN value is the hostname of your central manager. Then, set HOST_ALIAS in your configuration files to that hostname.

If the HTCondor daemons on all of your machines have the same SSL certificate (so that clients can authenticate themselves to servers), you will need a mapfile, which will tell the server that the clientâs certificate is trustworthy.
In your configuration files, add this line:

CERTIFICATE_MAPFILE = /etc/condor/condor_mapfile

Then, create the named file and put this line in it (modify to use your full certificate subject):

SSL "/O=example/CN= My cluster olac2" condor

 - Jaime

> On Jul 7, 2023, at 2:52 PM, Rita <rmorgan466@xxxxxxxxx> wrote:
> 
> Using HTcondor with ssl as my authentication mechanism (deamon to demon communication). I am not using a map file.
> 
> I keep getting an error when trying to start up my pool demons.
> Certificate common name(CN), "My cluster olac2, does not match host kilosa"