Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

When using a Smart card on Linux, and getting “This certificate (or its chain) is not valid"

11 April,19 at 11:50 AM

Troubleshooting Tip when using a Smart card on Centrified Linux, and getting “This certificate (or its chain) is not valid”:

 

Here’s a troubleshooting tip I learned recently from Centrify Engineering that I wanted to pass on.  It concerns using a smart card to login to a Red Hat (or CentOS) Linux system at the desktop GUI, and it involves the proper validation of the certificates on that smart card.  The basic problem scenario was as follows: There was an Active Directory user who could use their smart card to login to Windows machines, who could also use that smart card to log into a Centrified Mac machine, however they could not get their smart card to work on a Centrified Red Hat machine.  The results of the Centrify command “sctool -D” were certificates that stated “This certificate (or its chain) is not valid”.  The Active Directory Group Policy that pushed out all the required root and intermediate certificates was being set at the Domain level, and therefore the Centrified Mac and the Centrified Red Hat were getting the same GPs from the same place.
 
Centrify Engineering wanted to run the Group Policy update tool “adgpupdate” in debug mode and look at the results, so we did the following commands :
 - addebug on
 - addebug clear
 - adgpupdate
 - grep -i runmapper /var/log/centrifydc.log
 
Looking thru the results of the grep command, Engineering saw a line that stated “/usr/share/centrifydc/mappers/machine/rhel_certgp.pl taking too long, killing”.   This was the culprit.  
 
The Centrify agent gets the certificates it need from Active Directory and processes them, which involves a few functions, one of which is executed by calling the mappers script called “rhel_certgp.pl”, and the aforementioned line in the debug log file indicates that this certificate processing script was not being allowed to complete.  This was causing the certificates on the smart card to be labeled as invalid, since the local machine did not properly have all the certificates from AD processed correctly.  This script normally should only take 10 seconds or so, and the default timeout value is 30 seconds, however in this case 30 seconds was not enough for some reason.  To give it plenty of time, we updated the value for this timeout to 150 seconds, reran “adgpupdate”, and this solved our problem.   After allowing this processing script to complete successfully, the output of the Centrify command “sctool -D” were certificates that stated “This certificate is valid”.  The user was then able to log into their Red Hat desktop machine with their smart card, and everything worked great.  We then ran the command “addebug off” to turn off debugging.
 
The variable in the centrifydc.conf configuration file (located under /etc/centrifydc/) that corresponds to this timeout value is called “gp.mappers.timeout”.  Don’t forget that if you modify variables via this file, you need to run “adreload” to force the agent to reload its settings.  There is a corresponding Centrify Group Policy as well, and it is a Computer GP called “Set group policy mapper execution timeout” that is located under Centrify Settings/DirectControl Settings / Group Policy Settings .

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

No related Articles