 |
 |
Hi Bockfoo, For the first case it appears to be a conflict between private and public IP addresses, 172.16.200.175 is private did you issue the command from a public address or a private address? Is cmsio3.rc.ufl.edu actually a redirector? Another thing that would be helpful is to set the envar XRD_LOGLEVEL to "Debug" and try the command again and send us the output. Andy On Thu, 19 May 2022, Bockjoo Kim wrote: > Hi Andy, > > I want to bring up this issue again. > > I don't understand why it's expected. > > For example, > > (base) [bockjoo@cms ~]$ xrdfs cmsio3.rc.ufl.edu ls /store/user/bockjoo > [FATAL] TLS error: Unable to validate 172.16.200.175; hostname not in SAN extension. > > I provided a fully qualified public hostname, but why is xrdfs coming up with a private ip 172.16.200.175 > > On the other hand, if I check a specific file, xrdfs does not show this issue and shows the correct output: > > (base) [bockjoo@cms ~]$ xrdfs cmsio3.rc.ufl.edu ls /store/user/bockjoo/xrdmapc.txt > /store/user/bockjoo/xrdmapc.txt > > I think this is a bug. > > Thanks, > > Bockjoo > > On 4/15/22 01:04, Andrew Hanushevsky wrote: >> 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