How to Use Proxy Certificates With SSL Authentication

These are instructions for upgrading from HTCondor-CE 5 (HTCondor 9.0) to HTCondor-CE 6 (HTCondor 10.X) while using X.509 proxies for authentication. In HTCondor 9.0, GSI authentication is used when the client has an X.509 proxy. This is not supported in HTCondor 10.0. Instead, plain SSL authentication can be used to authenticate a client' proxy. Once this upgrade process is complete, sites and VOs can work on transitioning to token authentication.

1 - Update to HTCondor 9.0.20

Both client and CE should upgrade to HTCondor 9.0.20. This new release adds a couple minor features to enable use of a proxy with plain SSL authentication. HTCondor 9.0.20 is a special release intended specifically to help CEs upgrade to HTCondor >= 10.7.0 with SSL authentication using proxies. It is hosted in a private repository.

To install on EL7-based distros we make use of the WLCG repository for the time being:

  yum install https://linuxsoft.cern.ch/wlcg/centos7/x86_64/wlcg-repo-1.0.0-1.el7.noarch.rpm
  yum install condor

On systems that already have an older version of HTCondor 9.0 installed, do 'update' instead of 'install'.

There are no new HTCondor-CE packages. Those can be installed from the existing repositories.

2 - Configure SSL authentication on the client

The CE client (e.g. the factory) should be configured to use a user proxy and grid CAs with SSL authentication. The following parameters should be set in the HTCondor configuration files.


  AUTH_SSL_USE_CLIENT_PROXY_ENV_VAR = True
  AUTH_SSL_CLIENT_CADIR = /etc/grid-security/certificates


If the client has the htcondor-ce-client package installed, then you can put these parameters in a new file /etc/condor-ce/config.d/90-ssl-auth,
otherwise e.g. in /etc/condor/config.d/90-ssl-auth

If the client is submitting directly to the CE via condor_submit or the python bindings, then X509_USER_PROXY must be set in the environment. If the client is using the grid universe and a local schedd to submit jobs to the CE, then "x509userproxy" must be set in the HTCondor submit file that's used to submit the grid universe job to the local schedd.

3 - Configure SSL authentication on the CE

The CE must be configured to accept proxy certificates and use grid credentials for SSL authentication. The following parameter should be set in the HTCondor-CE configuration files:


AUTH_SSL_ALLOW_CLIENT_PROXY = True
AUTH_SSL_REQUIRE_CLIENT_MAPPING = True

This next line is not needed for job submissions, but would be needed if a CE admin wants to continue
monitoring all glide-ins (if you do not know what that term means, you do not need this setting):


COLLECTOR.ALLOW_ADVERTISE_STARTD = $(UNMAPPED_USERS), $(USERS), ssl@unmapped


You can put these parameters in a new file /etc/condor-ce/config.d/90-ssl-auth

In addition, ensure the following parameters are uncommented in /etc/condor-ce/config.d/01-ce-auth.conf:


  AUTH_SSL_SERVER_CERTFILE = /etc/grid-security/hostcert.pem
  AUTH_SSL_SERVER_KEYFILE = /etc/grid-security/hostkey.pem
  AUTH_SSL_SERVER_CADIR = /etc/grid-security/certificates
  AUTH_SSL_CLIENT_CERTFILE = /etc/grid-security/hostcert.pem
  AUTH_SSL_CLIENT_KEYFILE = /etc/grid-security/hostkey.pem
  AUTH_SSL_CLIENT_CADIR = /etc/grid-security/certificates

Finally, remove (or comment out) the following line in /usr/share/condor-ce/mapfiles.d/50-common-default.conf,
even though the header in that file says not to edit this file:


  SSL /\/CN=([.A-Za-z0-9\/=[:space:]-]+)/ \1@unmapped.htcondor.org

Otherwise the fallback from SSL to GSI cannot work...

4 - Map the users' DNs to local accounts

The client's certificate subject must be added to HTCondor-CE's mapfiles by creating one or more files under /etc/condor-ce/mapfiles.d/. The format is similar to the traditional gridmapfile, but with some notable differences. The main difference is an additional field at the start of each line indicating the authentication method (SSL in this case).

Mapping a single certificate looks like this:


  SSL    "/O=condor/OU=CHTC Pool/CN=James Frey"    jfrey


You can also use a regular expression to map a set of certificates. To do this, put forward slashes around the subject instead of double quotes and escape any slashes or spaces in the subject field with backslashes. Here's an example:


  SSL    /\/O=condor\/OU=CHTC\ Pool\/CN=.*/    jfrey


Concerning the ops VO, please map at least the following certificates:

  • EGI Monitoring Service:
    • "/DC=EU/DC=EGI/C=GR/O=Robots/O=Greek Research and Technology Network/CN=Robot:argo-egi@grnet.gr"
    • "/DC=EU/DC=EGI/C=HR/O=Robots/O=SRCE/CN=Robot:argo-egi@cro-ngi.hr"
  • EGI Security monitoring:
    • "/DC=EU/DC=EGI/C=GR/O=Robots/O=Greek Research and Technology Network/CN=Robot:argo-secmon@grnet.gr"


5 - Test the SSL authentication

To test SSL authentication, you can disable GSI authentication for either the client or the CE.

In the client configuration, set the following configuration parameter to disable GSI:


  SEC_CLIENT_AUTHENTICATION_METHODS = FS, TOKEN, SCITOKENS, SSL


In the CE configuration, set the following configuration parameters to disable GSI (for now, not recommended):


  SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,TOKEN,SCITOKENS,SSL
  SCHEDD.SEC_READ_AUTHENTICATION_METHODS = FS,TOKEN,SCITOKENS,SSL

If you want to keep GSI authentication as a fallback (recommended for now), you can configure the CE to try SSL before GSI by setting the following parameters:


  SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,TOKEN,SCITOKENS,SSL,GSI
  SCHEDD.SEC_READ_AUTHENTICATION_METHODS = FS,TOKEN,SCITOKENS,SSL,GSI
SCHEDD.AUTH_SSL_REQUIRE_CLIENT_CERTIFICATE = True


If from your condor client you launch a command like the following one, you can easily see if the authentication works as expected:

$ condor_ping -verbose -pool ce14.pic.es:9619 -name ce14.pic.es -type schedd write
Destination:                 schedd ce14.pic.es
Remote Version:              $CondorVersion: 9.0.20 Nov 15 2023 BuildID: 690225 PackageID: 9.0.20-1 $
Local  Version:              $CondorVersion: 9.0.20 Nov 15 2023 BuildID: 690225 PackageID: 9.0.20-1 $
Session ID:                  ce14:637514:1700657379:28435
Instruction:                 write
Command:                     60021
Encryption:                  AES
Integrity:                   AES
Authenticated using:         SSL
All authentication methods:  SSL,GSI
Remote Mapping:              ops004@pic.es
Authorized:                  TRUE

6 - Upgrade to HTCondor-CE 6 and HTCondor >= 10.7.0 and install the EGI Check-in plugin

Once all of the peers of a given client or CE are authenticating successfully via SSL, you can upgrade to HTCondor-CE 6 and HTCondor >= 10.7.0 (Feature Channel). In order to use EGI Check-In tokens, the CE needs to be running HTCondor 10.4.0 or later.

Please follow these instruction to properly install and configure the EGI Check-in plugin: https://github.com/EGI-Federation/check-in-validator-plugin

Finally, please keep the SSL configuration enabled for the time being to allow the VOs a smooth transitioning to tokens.

In the early months of 2024, we will launch another campaign to get all HTCondor CEs upgraded to v23 or later,
providing example configuration instructions.

7 - Accounting setting for HTCondor >= 10

In order to allow APEL to properly retrieve the accounting information, please ensure to have the following setting under /etc/condor-ce/config.d and /etc/condor/config.d:

   USE_VOMS_ATTRIBUTES = True


  • No labels