 |
 |
Hi Bockjoo, This is expected and normal behaviour. If the machine van be known by more than one name then it's host cert must have all of these listed in SAN extension. I suggest you either not give it two name (i.e. use the name in tghe cert) or get a new cert with the all the names in the SAN extension. Some people also put the host's IP address(s) in the SAN extension as a client might use an IP address to reach the host. Andy On Thu, 14 Apr 2022, Bockjoo Kim wrote: > Hi, > > With the xrootd servers, I am seeing this error: > > (base) [bockjoo@cms ~]$ time xrdfs cmsio2.rc.ufl.edu ls /store/mc > [FATAL] TLS error: Unable to validate 172.16.199.254; hostname not in SAN > extension. > > The machine's FQHN is set at cmsio2.ufhpc ( 172.16.199.254 ) by the local > cluster management team but cmsio2.rc.ufl.edu is the publicly accessible > FQHN. > > So, I guess xrdfs is looking for the DN matching to the cmsio2.ufhpc instead > of cmsio2.rc.ufl.edu. > > Is this expected? > > When we were using the non-xrootd security system, I did not see this issue. > > Is there any workaround in terms of xrootd directive or something? > > Thanks, > > Bockjoo > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1