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
|