HTTP-TPC failing with Certificates do not conform to algorithm constraints

[vokac]

Why dCache HTTP-TPC transfers fails with "Certificates do not conform to algorithm constraints"? How can I get more details what exactly went wrong?

export SRC=https://tech-gftp.hep.technion.ac.il:8443/atlas/atlasscratchdisk/SAM/1M
export DST=https://dcache.farm.particle.cz/atlas/atlasscratchdisk/x
export TSRC=$(curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:DOWNLOAD"], "validity": "PT30M"}' "$SRC" | jq -r '.macaroon')
export TDST=$(curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:UPLOAD,DELETE,LIST,MANAGE"], "validity": "PT30M"}' "$DST" | jq -r '.macaroon')

curl -v --capath /etc/grid-security/certificates -X COPY -H 'Credential: none' -H "Authorization: Bearer $TDST" -H "TransferHeaderAuthorization: Bearer $TSRC" -H "Source: $SRC" "$DST"
*   Trying 2001:718:401:6025:1:0:1:80:443...
* Connected to dcache.farm.particle.cz (2001:718:401:6025:1:0:1:80) port 443 (#0)
...
> COPY /atlas/atlasscratchdisk/x HTTP/1.1
> Host: dcache.farm.particle.cz
> User-Agent: curl/7.76.1
> Accept: */*
> Credential: none
> Authorization: Bearer ...
> TransferHeaderAuthorization: Bearer ...
> Source: https://tech-gftp.hep.technion.ac.il:8443/atlas/atlasscratchdisk/SAM/1M
> 
...
< HTTP/1.1 202 Accepted
< Date: Wed, 29 Oct 2025 06:33:41 GMT
< Server: dCache/11.0.7
< Content-Type: text/perf-marker-stream
< Transfer-Encoding: chunked
< 
...
failure: Certificates do not conform to algorithm constraints

This error comes from dCache 11.0.7 running on AlmaLinux 9 with DEFAULT crypto policy. If I change crypto policy to DEFAULT:SHA1 than transfer succeeds. Certificate chain provided by tech-gftp.hep.technion.ac.il:8443 comes with one "unnecessary" non-IGTF Root CA from AAA Certificate Services, but considering included CaNL-java version 2.8.3 this one should be ignored

echo | openssl s_client -CApath /home/vokac/storage/canl-java-test/certificates -connect tech-gftp.hep.technion.ac.il:8443 -showcerts
Connecting to 2001:bf8:900:d:2::71
CONNECTED(00000003)
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=NL, O=GEANT Vereniging, CN=GEANT eScience SSL CA 4
verify return:1
depth=0 DC=org, DC=terena, DC=tcs, C=IL, ST=Haifa, O=Technion Israel Institute of Technology, CN=tech-gftp.hep.technion.ac.il
verify return:1
---
Certificate chain
 0 s:DC=org, DC=terena, DC=tcs, C=IL, ST=Haifa, O=Technion Israel Institute of Technology, CN=tech-gftp.hep.technion.ac.il
   i:C=NL, O=GEANT Vereniging, CN=GEANT eScience SSL CA 4
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Dec 17 00:00:00 2024 GMT; NotAfter: Dec 17 23:59:59 2025 GMT
-----BEGIN CERTIFICATE-----
MIIH+DCCBeCgAwIBAgIRAI73rznT/ORcSgkvQhS1804wDQYJKoZIhvcNAQEMBQAw
SjELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxIDAeBgNV
BAMTF0dFQU5UIGVTY2llbmNlIFNTTCBDQSA0MB4XDTI0MTIxNzAwMDAwMFoXDTI1
MTIxNzIzNTk1OVowgbgxEzARBgoJkiaJk/IsZAEZFgNvcmcxFjAUBgoJkiaJk/Is
ZAEZFgZ0ZXJlbmExEzARBgoJkiaJk/IsZAEZFgN0Y3MxCzAJBgNVBAYTAklMMQ4w
DAYDVQQIEwVIYWlmYTEwMC4GA1UEChMnVGVjaG5pb24gSXNyYWVsIEluc3RpdHV0
ZSBvZiBUZWNobm9sb2d5MSUwIwYDVQQDExx0ZWNoLWdmdHAuaGVwLnRlY2huaW9u
LmFjLmlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5OPsfcBcGQfy
r5fXWPJdeeDhs7z3x/bcSA2uKG7e8H991ShMZ3dYXEEI/sgvDX2egduREpfE1eRL
NkVBD5nIXjirGEKkvVEaAOBLUeIpb1lJcXM02hZbuwXFfwVCbqlo7qkYvpMmFgMY
q3ys2/Y6/tKqL9JSpnBQeNy4n95aY7CQgY4LQbdI32HBJYDTSD0tV+Fv5dkexjpq
16fQFxl+dUcxPEIugaH2XCZH56S06/XFBz8vxrPOhsXus+eFNYNqEiCxLWiwUAwM
2ukhCwEq9j39N/4I3By/1dk73tRWMcXu+z9kjyoXiUmZVdtltCqaycV6n9tae2Ba
hxEDsD+s5QIDAQABo4IDaDCCA2QwHwYDVR0jBBgwFoAUmiuKItaNDMAqpW9kMz+W
YGcVHbIwHQYDVR0OBBYEFP3WP3EdLrcEBlLQ2amhLNb/3Ri7MA4GA1UdDwEB/wQE
AwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD
AjB1BgNVHSAEbjBsMAwGCiqGSIb3TAUCAgEwDQYLKoZIhvdMBQIDAwIwDQYLKoZI
hvdMBQIDAQIwNAYLKwYBBAGyMQECAk8wJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9z
ZWN0aWdvLmNvbS9DUFMwCAYGZ4EMAQICMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6
Ly9HRUFOVC5jcmwuc2VjdGlnby5jb20vR0VBTlRlU2NpZW5jZVNTTENBNC5jcmww
ewYIKwYBBQUHAQEEbzBtMEAGCCsGAQUFBzAChjRodHRwOi8vR0VBTlQuY3J0LnNl
Y3RpZ28uY29tL0dFQU5UZVNjaWVuY2VTU0xDQTQuY3J0MCkGCCsGAQUFBzABhh1o
dHRwOi8vR0VBTlQub2NzcC5zZWN0aWdvLmNvbTCCAX8GCisGAQQB1nkCBAIEggFv
BIIBawFpAHUA3dzKNJXX4RYF55Uy+sef+D0cUN/bADoUEnYKLKy7yCoAAAGT09wV
hwAABAMARjBEAiBHVbHO4AXOLqB+lVCCiO/uBwnxKntRHOPSF7EDhp4bwgIgecC2
9W6bZO+kMf4+bQ4gQBvRJPmQJjjeVRPjE3Sar6QAdwDM+w9qhXEJZf6Vm1PO6bJ8
IumFXA2XjbapflTA/kwNsAAAAZPT3BYsAAAEAwBIMEYCIQCGDQ6ilLVGeTOYGy/O
xRGnloVWDpYoFuHN4kAkGqf3aAIhAPEmsE+eE2xrDJqm+ikwuotfBmVebbS73PWo
J5hMR7gzAHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGT09wV
IAAABAMASDBGAiEAxsOQpABoe7WtC3OxISBwEUOpuPrQsThlQkTTuVtn3goCIQCx
TKMa/Epz+cKnCSW1c/yQyoV/QKBRyrnwtaXNnUnOqjAnBgNVHREEIDAeghx0ZWNo
LWdmdHAuaGVwLnRlY2huaW9uLmFjLmlsMA0GCSqGSIb3DQEBDAUAA4ICAQCMe9fd
wtzE6ftuYTEwHgZkAaYCw+EGA2BEacLtqR1OfQ2q5cE42Kdx4qu/2Hs2qHrZhy4T
2guAiQWD5C61UPz8PbfGIe1U7RLuK7VBIn5hdASLPzc037C3ByCf70RKqraAdcMC
TMorgzG5mJowXvz02wMmWPmupEKRygUQucPMsY7lzmp9kFkPDINmXcukmGuLYfeY
Pj2nYJYsqOXOJ+efkNBcfzD/EePE1jDVsiP8yjtoGqQnxH+Z9mAIZA23uSV+0Bia
LdRV1u34HfSuXWfvr2lHl6ukjOsCPhO9lLoryF2Al5dqvygaJapjW1Id57uFa+jS
IeskfHOMyz2f4HOQ9LdVFP/W3jTpBcsbdPZ2g7DIWC+h14UfXOl6E/jcaqlz6jal
B3w57r1NhNPA644l9raonCiIEgDLGaVO7Bpi+3ISO5IlnX+L/SMVATSc9nQ58qIS
7xNJphOvtuzB9nq9PlUCdBUMbPVGGtXfrotEbig9aiL1CM/uiF2krgo3Pwug99X9
gactw8dlE6cuQDT79ZXmJtEWsJZLjr65CAW6Gy1nA0cXpFvXXh8lh5dawcuf8VKK
iO/V2zRoThTNzB+ZgJlBr80GNuwnLpR4ZSm0OSemV0oP38WYVaqKMqfpaFRAj50Z
VU13jDyT+zxiDy01jLOJkKe03NhGg+xtH/q/iQ==
-----END CERTIFICATE-----
 1 s:C=NL, O=GEANT Vereniging, CN=GEANT eScience SSL CA 4
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Feb 18 00:00:00 2020 GMT; NotAfter: May  1 23:59:59 2033 GMT
-----BEGIN CERTIFICATE-----
MIIG6jCCBNKgAwIBAgIQN9uaOAbXCsc+ONHf725RKjANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMjAw
MjE4MDAwMDAwWhcNMzMwNTAxMjM1OTU5WjBKMQswCQYDVQQGEwJOTDEZMBcGA1UE
ChMQR0VBTlQgVmVyZW5pZ2luZzEgMB4GA1UEAxMXR0VBTlQgZVNjaWVuY2UgU1NM
IENBIDQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCUtBhby5HZ4dxN
stR0OaxF/QrC0FENJm59Na5LZzPwXqwTdaq1NJUZwMIrHTXavExQpGqzdqwIKNS0
liyLkTT54vTs5VPh5SYRFtVAX9NLkY+fUIu2icOEGfwlPR6VlYp+kiR2Vj4OwYhy
aM0tj66uaTCaAj3Rz99dN1s64Z1jw/wjckCLat/MGHL4crKuQErYyPfoK1s39BR/
gXis0E2anvfmuyAZ3YDOsAyGKpPhEj3Dxuiz5+qpqJIePs3Vgylyx/ZIoJEH/jAq
v7GbdVTsSfqyMlnyceF0pyGQ6Yzp1DkLw4Dg26zoOSckLYeICtRziSwzrMu3YLYW
VB6h1r0Nw/hnuXMYt6WgLYekfxuwapwbntbw5gAJpK63geBp3Hj7bWnrPb8aLjBz
eutA2St+Y6YodQ8PjbhUpaWVMGzz+c2YJK/xbxTAjWUPOdd8cNrM7ilaOrvbSaLz
e7aPBFWZMpg1kOva5J91qSdOmS45DHyyfT4Xk2X/3HhFRLkKA/cdJaEYE1I/p0P5
A2qFlMdr+QDx7Uar5Zvsbvrm0gn+MER1uq3xugoweC3iegHwQQh4YupAEamo1vPy
n04r3WPn86rLjpe0OLFvlM8CQtvTWV6wOXy3HTnIh8gFGxe/0Wu3XYBtPcJXlBMO
aV7NDi69LE9ZiYNF+wBZ6iUgVw3ZRQIDAQABo4IBizCCAYcwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFJoriiLWjQzAKqVvZDM/lmBn
FR2yMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjA4BgNVHSAEMTAvMC0GBFUdIAAwJTAjBggr
BgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwUAYDVR0fBEkwRzBFoEOg
QYY/aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmlj
YXRpb25BdXRob3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYz
aHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0Eu
Y3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqG
SIb3DQEBDAUAA4ICAQAmpZcT3x9evRVo7pAAsdyTx3mmtbOGWIAQFQRiW4po1Jx9
9szSmymPrzDq0s1Lh7EL+sworQnNKEApLYpcFZ/ZeyjWPt+7D/SKGdjhFE9owf71
hNiwWBWzMHZWE/1lYpISw2gbclDk6Mp1GkDQhRVXQL5O6uXeouxNiKpAXZj8QFx7
Sk1kkuXewca4dFRTs9Oadec8ARnR+YzxhTE0p3m2rBkWL3zpNCtl+7zpPJm58eCc
8Oxt7ib/XwoZKE/tKKZ6rcA+kBL6X6xeim+DwVqToJW24yiqVAI2JYQw1741fqm8
lklFlkAoOTJTprMd3jIK2DKYvAXkZiAeY8eD85AVCJgC+DpD/0Oc3OpsP5kljGzF
2rUYGLutL1a9Uxd2YCGkqnAym2f2LsBo5u2+Znk5YzfD5xPSWBrs9K5UtE2G+5B0
iygvf+yl/+hcv4aN3zetNXbfsSArAR0ecdNkNtehXeVaFE7rIZUXFahzHn2cSOLO
n4vjBWKRHJc4lvlqhfz1jaPrcxS0BxaJq0VNrX3skPeajbVSsPAjXXVDh9I5qjdG
yMvAe5TUyUf752JKBN56Zi5mvz5ufbvULGcV4Frnwl2c2ySICF7KGIB+KGhGbgbf
tN6PKXHwC3gvRw9yzFSq6Rdwh7U+3AkmDel0rhdZnMTx2JryjQF/AeBKwkfrUQ==
-----END CERTIFICATE-----
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
-----BEGIN CERTIFICATE-----
MIIFgTCCBGmgAwIBAgIQOXJEOvkit1HX02wQ3TE1lTANBgkqhkiG9w0BAQwFADB7
MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE
AwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTE5MDMxMjAwMDAwMFoXDTI4
MTIzMTIzNTk1OVowgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5
MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO
ZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sI
s9CsVw127c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnG
vDoZtF+mvX2do2NCtnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQ
Ijy8/hPwhxR79uQfjtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfb
IWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0
tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97E
xwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNV
icQNwZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5
D9kCnusSTJV882sFqV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJ
WBp/kjbmUZIO8yZ9HE0XvMnsQybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ
5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzG
KAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaOB8jCB7zAfBgNVHSMEGDAWgBSg
EQojPpbxB+zirynvgqV/0DCktDAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rID
ZsswDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAG
BgRVHSAAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t
L0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUA
A4IBAQAYh1HcdCE9nIrgJ7cz0C7M7PDmy14R3iJvm3WOnnL+5Nb+qh+cli3vA0p+
rvSNb3I8QzvAP+u431yqqcau8vzY7qN7Q/aGNnwU4M309z/+3ri0ivCRlv79Q2R+
/czSAaF9ffgZGclCKxO/WIu6pKJmBHaIkU4MiRTOok3JMrO66BQavHHxW/BBC5gA
CiIDEOUMsfnNkjcZ7Tvx5Dq2+UUTJnWvu6rvP3t3O9LEApE9GQDTF1w52z97GA1F
zZOFli9d31kWTz9RvdVFGD/tSo7oBmF0Ixa1DVBzJ0RHfxBdiSprhTEUxOipakyA
vGp4z7h/jnZymQyd/teRCBaho1+V
-----END CERTIFICATE-----
 3 s:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
   v:NotBefore: Jan  1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgIBATANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJHQjEb
MBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRow
GAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UEAwwYQUFBIENlcnRpZmlj
YXRlIFNlcnZpY2VzMB4XDTA0MDEwMTAwMDAwMFoXDTI4MTIzMTIzNTk1OVowezEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMM
GEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL5AnfRu4ep2hxxNRUSOvkbIgwadwSr+GB+O5AL686tdUIoWMQua
BtDFcCLNSS1UY8y2bmhGC1Pqy0wkwLxyTurxFa70VJoSCsN6sjNg4tqJVfMiWPPe
3M/vg4aijJRPn2jymJBGhCfHdr/jzDUsi14HZGWCwEiwqJH5YZ92IFCokcdmtet4
YgNW8IoaE+oxox6gmf049vYnMlhvB/VruPsUK6+3qszWY19zjNoFmag4qMsXeDZR
rOme9Hg6jc8P2ULimAyrL58OAd7vn5lJ8S3frHRNG5i1R8XlKdH5kBjHYpy+g8cm
ez6KJcfA3Z3mNWgQIJ2P2N7Sw4ScDV7oL8kCAwEAAaOBwDCBvTAdBgNVHQ4EFgQU
oBEKIz6W8Qfs4q8p74Klf9AwpLQwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20v
QUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDANBgkqhkiG9w0BAQUF
AAOCAQEACFb8AvCb6P+k+tZ7xkSAzk/ExfYAWMymtrwUSWgEdujm7l3sAg9g1o1Q
GE8mTgHj5rCl7r+8dFRBv/38ErjHT1r0iWAFf2C3BUrz9vHCv8S5dIa2LX1rzNLz
Rt0vxuBqw8M0Ayx9lt1awg6nCpnBBYurDC/zXDrPbDdVCYfeU0BsWO/8tqtlbgT2
G9w84FoVxp7Z8VlIMCFlA2zs6SFz7JsDoeA3raAVGI/6ugLOpyypEBMs1OUIJqsi
l2D4kF501KKaU73yqWjgom7C12yxow+ev+to51byrvLjKzg6CYG1a4XXvi3tPxq3
smPi9WIsgtRqAEFQ8TmDn5XpNpaYbg==
-----END CERTIFICATE-----

I don't understand where this dCache error Certificates do not conform to algorithm constraints comes from, it is probably raised by following Bouncy Castle code

https://github.com/bcgit/bc-java/blob/b0c629c9b824818a1e16025dcf923d0bc1d74eae/tls/src/main/java/org/bouncycastle/jsse/provider/ImportX509TrustManager_5.java#L114

but I'm not able to reproduce this error using simple CaNL client

import eu.emi.security.authn.x509.impl.OpensslCertChainValidator;
import eu.emi.security.authn.x509.impl.ValidatorParams;
import eu.emi.security.authn.x509.helpers.ssl.SSLTrustManager;
import eu.emi.security.authn.x509.NamespaceCheckingMode;
import eu.emi.security.authn.x509.OCSPParametes;
import eu.emi.security.authn.x509.OCSPCheckingMode;
import eu.emi.security.authn.x509.RevocationParameters;
import eu.emi.security.authn.x509.CrlCheckingMode;
import eu.emi.security.authn.x509.ProxySupport;
import eu.emi.security.authn.x509.StoreUpdateListener;
import eu.emi.security.authn.x509.ValidationError;
import eu.emi.security.authn.x509.ValidationResult;
import eu.emi.security.authn.x509.X509CertChainValidator;

import javax.net.ssl.*;
import javax.net.ssl.X509TrustManager;
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.security.KeyStore;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.nio.file.Path;
import java.nio.file.Paths;

public class CanlSSLClient {
    private static class LoggingTrustManager extends SSLTrustManager {
        public LoggingTrustManager(X509CertChainValidator validator) {
            super(validator);
        }

        @Override
        public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
            System.out.println("Validating server certificate chain: " + authType);
            for (X509Certificate cert : chain) {
                System.out.println(" - Subject: " + cert.getSubjectX500Principal());
                System.out.println(" - Issuer: " + cert.getIssuerX500Principal());
            }
            super.checkServerTrusted(chain, authType);
            System.out.println("Server certificate validation passed.");
        }

        @Override
        public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
            System.out.println("Validating client certificate chain: " + authType);
            super.checkClientTrusted(chain, authType);
            System.out.println("Client certificate validation passed.");
        }
    }
    private static X509TrustManager buildTrustManager(Path path) {
        var namespaceMode = NamespaceCheckingMode.EUGRIDPMA_AND_GLOBUS_REQUIRE;
        var ocspParameters = new OCSPParametes(OCSPCheckingMode.IGNORE);
        var revocationParams = new RevocationParameters(CrlCheckingMode.REQUIRE, ocspParameters);
        var validatorParams = new ValidatorParams(revocationParams, ProxySupport.ALLOW);
        long updateInterval = 60000;
        var validator = new OpensslCertChainValidator(path.toString(), true, namespaceMode, updateInterval, validatorParams, false);
        validator.addUpdateListener(new StoreUpdateListener() {
            @Override
            public void loadingNotification(String location, String type, Severity level, Exception cause) {
                System.out.println("loading: " + location + " (type " + type + ", level " + level + ", " + cause + ")");
            }
        });
        validator.addValidationListener((ValidationError error) -> {
            System.out.println("validation error: " + error);
            return false;
        });
        //return new SSLTrustManager(validator);
        return new LoggingTrustManager(validator);
    }
    public static void main(String[] args) throws Exception {
        if (args.length < 4) {
            System.out.println("Usage: java CanlSSLClient <keystore.p12> <keystorePassword> <trustedCaPath> <host> [port]");
            return;
        }

        String keystorePath = args[0];
        String keystorePassword = args[1];
        String trustedCaPath = args[2];
        String host = args[3];
        int port = args.length > 4 ? Integer.parseInt(args[4]) : 443;
        String path = args.length > 5 ? args[5] : "/";

        // Load PKCS#12 keystore
        KeyStore keyStore = KeyStore.getInstance("PKCS12");
        keyStore.load(new FileInputStream(keystorePath), keystorePassword.toCharArray());

        // Create KeyManager from keystore
        KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
        kmf.init(keyStore, keystorePassword.toCharArray());

        // Create TrustManager
        X509TrustManager trustManager = buildTrustManager(Paths.get(trustedCaPath));

        // Create SSL context
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(kmf.getKeyManagers(), new TrustManager[]{trustManager}, null);

        // Create socket and connect
        SSLSocketFactory factory = sslContext.getSocketFactory();
        SSLSocket socket = (SSLSocket) factory.createSocket(host, port);
        socket.startHandshake();

        // Send request
        OutputStream out = socket.getOutputStream();
        out.write(("GET " + path + " HTTP/1.1\r\nHost: " + host + "\r\n\r\n").getBytes());
        out.flush();

        // Read response
        InputStream in = socket.getInputStream();
        byte[] buffer = new byte[4096];
        int bytesRead = in.read(buffer);
        System.out.println(new String(buffer, 0, bytesRead));

        socket.close();
    }
}

How to test exactly what dCache is doing during HTTP-TPC? This code works:

openssl pkcs12 -export  -in client-cert.pem -inkey client-key.pem -out client-keystore.p12 -name client -password pass:changeit
javac -cp .:canl-2.8.3.jar CanlSSLClient.java
java -cp .:canl-2.8.3.jar:bcpkix-jdk18on-1.78.jar:bcprov-jdk18on-1.78.jar:bcutil-jdk18on-1.78.jar:commons-io-2.15.1.jar CanlSSLClient client-keystore.p12 changeit /etc/grid-security/certificates tech-gftp.hep.technion.ac.il 8443 /atlas/atlasscratchdisk/SAM/1M

Validating server certificate chain: UNKNOWN
 - Subject: CN=tech-gftp.hep.technion.ac.il, O=Technion Israel Institute of Technology, ST=Haifa, C=IL, DC=tcs, DC=terena, DC=org
 - Issuer: CN=GEANT eScience SSL CA 4, O=GEANT Vereniging, C=NL
 - Subject: CN=GEANT eScience SSL CA 4, O=GEANT Vereniging, C=NL
 - Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
 - Subject: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
 - Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
 - Subject: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
 - Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
Server certificate validation passed.
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=node01ns2o3p1923pjy7v3y1mo0lxh20754.node0; Path=/; Secure
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Digest: adler32=f00001
Last-Modified: Mon, 13 May 2024 22:14:46 GMT
Accept-Ranges: bytes
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Transfer-Encoding: chunked

100000

[DmitryLitvintsev]

I believe this issue is solved by:

 update-crypto-policies --set DEFAULT:SHA1

followed by door and pool nodes reboots!

This is needed because some of the root CA certificates are still sha1 encrypted.

At least this is what we have seen on CMS T1 dCache and how we addressed it.

[maarten-litmaath]

Hi both,
the SHA-1 certificate is the last one:

CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB

The output of Petr's program is misleading, see below.

The queried service presents a chain of 4 certificates (as also shown above):

$ openssl s_client -connect tech-gftp.hep.technion.ac.il:8443 -key ~/.globus/userkey.pem -cert ~/.globus/usercert.pem -showcerts < /dev/null | sed -n '/ /p;/^Server/q'
[...]
Certificate chain
0 s:DC=org, DC=terena, DC=tcs, C=IL, ST=Haifa, O=Technion Israel Institute of Technology, CN=tech-gftp.hep.technion.ac.il
i:C=NL, O=GEANT Vereniging, CN=GEANT eScience SSL CA 4
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Dec 17 00:00:00 2024 GMT; NotAfter: Dec 17 23:59:59 2025 GMT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
1 s:C=NL, O=GEANT Vereniging, CN=GEANT eScience SSL CA 4
i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Feb 18 00:00:00 2020 GMT; NotAfter: May 1 23:59:59 2033 GMT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
3 s:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
v:NotBefore: Jan 1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
Server certificate

We see that the third certificate (number 2) is not signed by itself,
whereas the supposedly corresponding one in IGTF is signed by itself:

$ openssl x509 -noout -subject -issuer -nameopt compat -in /etc/grid-security/certificates/USERTrustRSACertificationAuthority.pem
subject=/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer=/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

I suppose this is an IGTF "trick" to allow verification to stop at that point
and thus ignore the final CA not being in IGTF (anymore).

The different behaviors found by Petr suggest that dCache somehow uses
canl-java in a way that makes it verify also that final certificate...

[vokac]

Just to be clear, we would like to get rid of DEFAULT:SHA1 workaround, because this is not so easily available on EL10. Also, CaNL-java (even older version then 2.8.3) doesn't really have problem with Root CA signed by SHA1, because this library doesn't verify signature of Root CA, e.g. you can test this behavior with FZK T1 storage that use Germany DFN CA signed by SHA1 and everything works fine without DEFAULT:SHA1 workaround, e.g. our dcache.farm.particle.cz running with DEFAULT crypto policy on EL9 succeeds with HTTP-TPC pull from FZK

export SRC=https://atlasdcache-kit.gridka.de:2880/pnfs/gridka.de/atlas/disk-only/atlasscratchdisk/SAM/1M
export DST=https://dcache.farm.particle.cz/atlas/atlasscratchdisk/x
export TSRC=$(curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:DOWNLOAD"], "validity": "PT30M"}' "$SRC" | jq -r '.macaroon')
export TDST=$(curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:UPLOAD,DELETE,LIST,MANAGE"], "validity": "PT30M"}' "$DST" | jq -r '.macaroon')

curl -v --capath /etc/grid-security/certificates -L -X COPY -H 'Credential: none' -H "Authorization: Bearer $TDST" -H "TransferHeaderAuthorization: Bearer $TSRC" -H "Source: $SRC" "$DST"
*   Trying 2001:718:401:6025:1:0:1:80:443...
* Connected to dcache.farm.particle.cz (2001:718:401:6025:1:0:1:80) port 443 (#0)
...
> COPY /atlas/atlasscratchdisk/x HTTP/1.1
> Host: dcache.farm.particle.cz
> User-Agent: curl/7.76.1
> Accept: */*
> Credential: none
> Authorization: Bearer setoken1
> TransferHeaderAuthorization: Bearer setoken2
> Source: https://atlasdcache-kit.gridka.de:2880/pnfs/gridka.de/atlas/disk-only/atlasscratchdisk/SAM/1M
> 
...
< HTTP/1.1 202 Accepted
< Date: Thu, 30 Oct 2025 08:58:52 GMT
< Server: dCache/11.0.7
< Content-Type: text/perf-marker-stream
< Transfer-Encoding: chunked
< 
...
success: Created

There was in the past an issue where CaNL-java < 2.8.3 validated useless certificates advertised by server, but this was already fixed and dCache > 10.1.0 comes with this fixed CaNL-java package.

This Certificates do not conform to algorithm constraints that we get while trying to talk HTTP-TPC pull with tech-gftp.hep.technion.ac.il:8443 is different issue and we would like to understand where it comes from and how to fix it (without crypto policy workaround). At least this generic error message directly from Bouncy Castle library is not really very helpful.

[DmitryLitvintsev]

SHA1 is a security risk and I would have expected the root CA should be re-issued w/ signature signed using SHA2 or SHA3 algorithms. It was my impression that the workaround is temporary until that happens.

TBH, I am not convinced that this is a problem. dCache is catching and refusing SHA1 signed root CA following OS system setting (DEFAULT vs DEFAULT:SHA1). And we are not doing anything special in our code (at first glance).

[maarten-litmaath]

Hi all,
I am not yet convinced the test demonstrated above is sufficient to show all is fine w.r.t. root certificate checks, though the result is also consistent with what the canl-java maintainer remembers. My point is that for proxy certificates, a different code path is followed necessarily, which in theory then could lead to different behavior in this respect: quite unlikely, I suppose, but I would prefer that a test be done also with an affected proxy...

[vokac]

I was probably wrong and error Certificates do not conform to algorithm constraints most probably comes directly form internal Java SSL implementation. This implementation skips validation of last certificate in the chain if that's trusted certificate

https://github.com/openjdk/jdk/blob/e8a1a8707ee6192c85ac62a2a51c815e07613c38/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L1502-L1504

but this is not the case for tech-gftp.hep.technion.ac.il:8443 which in the chain has one additional certificate (that I guess allows services which rely on CAB to see this service also as trusted).

What's not clear to me why dCache use this code in a first place even if I set pool.authn.namespace-mode=${dcache.authn.namespace-mode}?

[paulmillar]

The issue was originally:

Why dCache HTTP-TPC transfers fails with "Certificates do not conform to algorithm constraints"? How can I get more details what exactly went wrong?

The phrase "Certificates do not conform to algorithm constraints" doesn't come from dCache, nor does it come from CaNL-java. It seems to come from OpenJDK.

From a quick search, it seems that OpenJDK includes this message (and only this message) when throwing certain exceptions. The causal chain for the exception likely includes an earlier exception that contains more precise information on what is the constraint to which the certificates do not conform. However, that earlier exception is not present: either CaNL doesn't pass it on to dCache or dCache ignores it.

Answering the question: how can I get more details what exactly went wrong?

I see two approaches:

1. updating how CaNL-Java and/or dCache handles these problems, so more actionable information is provided.
2. Use OpenJDK's built-in logging support to log the problem.

Option 1. is attractive because it would allow the HTTP-TPC to describe the problem back to the user, which is a powerful way to help fix the problem (the user is often motivated)

Option 2. shouldn't require any code changes (so should be faster), but requires the dCache admin to enable configuration changes and monitor the updated service (as the user reproduces the problem).

There are various options to enable more debugging output in OpenJDK's security-related APIs --- certainly for TLS but also (I believe) for certificate verification. These are Java system properties that should be enabled.

[kofemann]

A was able to crate a simple reproducer

@Test
public void testIssue7927Canl() throws Exception {

  var ocspParameters = new OCSPParametes(OCSPCheckingMode.IF_AVAILABLE);
  var revocationParams = new RevocationParameters(CrlCheckingMode.REQUIRE, ocspParameters);
  var validatorParams = new ValidatorParams(revocationParams, ProxySupport.ALLOW);
  var validator = new OpensslCertChainValidator("etc/grid-security/certificates/", true,
          NamespaceCheckingMode.EUGRIDPMA_AND_GLOBUS, 10_000, validatorParams, false);

  var trustManager =  new SSLTrustManager(validator);

  SSLContext context = SSLContext.getInstance("TLS");
  java.security.SecureRandom secureRandom = new java.security.SecureRandom();
  context.init(new KeyManager[0], new TrustManager[]{trustManager}, secureRandom);

  try (var client = HttpClients.custom().setSSLContext(context).build()) {
      var rr = new HttpHead("https://tech-gftp.hep.technion.ac.il:8443/atlas/atlasscratchdisk/SAM/1M");
      client.execute(rr);
  }
}

@Test
public void testIssue7927Java() throws Exception {

  try (var client = HttpClients.custom().build()) {
      var rr = new HttpHead("https://tech-gftp.hep.technion.ac.il:8443/atlas/atlasscratchdisk/SAM/1M");
      client.execute(rr);
  }
}

The testIssue7927Java passes, testIssue7927Canl failed with an exception:

javax.net.ssl.SSLHandshakeException: (unsupported_certificate) Certificates do not conform to algorithm constraints

	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:383)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1287)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1164)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1107)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:393)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:477)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:448)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:206)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1506)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1421)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
	at org.dcache.pool.movers.Foo.testIssue7927Canl(Foo.java:43)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
	at com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
	at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1557)
	at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1484)
	at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1431)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1271)
	... 49 more
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: SHA1withRSA
	at java.base/sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:231)
	at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1553)
	... 52 more

Thus, this is not a pure Java issue, but rather a dcache/canl restriction.

[DmitryLitvintsev]

@paulmillar I believe Petr found where the exception is thrown:

https://github.com/bcgit/bc-java/blob/b0c629c9b824818a1e16025dcf923d0bc1d74eae/tls/src/main/java/org/bouncycastle/jsse/provider/ImportX509TrustManager_5.java#L114

[DmitryLitvintsev]

@kofemann Isn't it CANL restriction (that is not dCache)?

[kofemann]

after a long day of debugging... JVM uses X509ExtendedTrustManager class to validate the host certificate. The CANL provides two implementations of TrustManagers: SSLTrustManagerWithHostnameChecking, which extends X509ExtendedTrustManager, and SSLTrustManager, which extends X509TrustManager. In case of the latter one, JDK will wrap with a AbstractTrustManagerWrapper implementation, which enforces additional checks

(https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L1411)

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType,
            SSLEngine engine) throws CertificateException {
        tm.checkServerTrusted(chain, authType);
        checkAdditionalTrust(chain, authType, engine, false);
    }

Thus, validation by OpensslCertChainValidator extended with unexpected checks.
I simple solution is to use SSLTrustManagerWithHostnameChecking in dCache 🎉

    @Test
    public void testIssue7927Canl() throws Exception {

        enableAlgorithms();


        var ocspParameters = new OCSPParametes(OCSPCheckingMode.IF_AVAILABLE);
        var revocationParams = new RevocationParameters(CrlCheckingMode.REQUIRE, ocspParameters);
        var validatorParams = new ValidatorParams(revocationParams, ProxySupport.ALLOW);
        var validator = new OpensslCertChainValidator("etc/grid-security/certificates/", true,
                NamespaceCheckingMode.EUGRIDPMA_AND_GLOBUS, 10_000, validatorParams, false);

        var trustManager =  new SSLTrustManagerWithHostnameChecking(validator, new EnforcingNameMismatchCallback());

        SSLContext context = SSLContext.getInstance("TLS");
        java.security.SecureRandom secureRandom = new java.security.SecureRandom();
        context.init(new KeyManager[0], new TrustManager[]{trustManager}, secureRandom);

        try (var client = HttpClients.custom().setSSLContext(context).build()) {
            var rr = new HttpHead("https://tech-gftp.hep.technion.ac.il:8443/atlas/atlasscratchdisk/SAM/1M");
            client.execute(rr);
        }
    }

[kofemann]

https://rb.dcache.org/r/14566/

[vokac]

Nice, I did not yet had time to dig into details. I compiled dCache with following patch and unfortunately got same error

diff --git a/modules/common-security/src/main/java/org/dcache/ssl/CanlContextFactory.java b/modules/common-security/src/main/java/org/dcache/ssl/CanlContextFactory.java
index f90bc8d4af..c59903114b 100644
--- a/modules/common-security/src/main/java/org/dcache/ssl/CanlContextFactory.java
+++ b/modules/common-security/src/main/java/org/dcache/ssl/CanlContextFactory.java
@@ -303,7 +306,7 @@ public class CanlContextFactory implements SslContextFactory {
                 }
                 return false;
             });
-            return new CanlContextFactory(startTls, new SSLTrustManager(v));
+            return new CanlContextFactory(startTls, new SSLTrustManagerWithHostnameChecking(v, new DisabledNameMismatchCallback()));
         }
 
         public <T> Callable<T> buildWithCaching(Class<T> contextType) throws Exception {
diff --git a/modules/dcache/src/main/java/org/dcache/pool/classic/RemoteHttpTransferService.java b/modules/dcache/src/main/java/org/dcache/pool/classic/RemoteHttpTransferService.java
index 85734d68b2..71338f374a 100644
--- a/modules/dcache/src/main/java/org/dcache/pool/classic/RemoteHttpTransferService.java
+++ b/modules/dcache/src/main/java/org/dcache/pool/classic/RemoteHttpTransferService.java
@@ -214,7 +217,7 @@ public class RemoteHttpTransferService extends SecureRemoteTransferService {
         var validator = new OpensslCertChainValidator(path.toString(), true,
               getNamespaceMode(), updateInterval, validatorParams, false);
         onShutdownTasks.add(validator::dispose);
-        return new SSLTrustManager(validator);
+        return new SSLTrustManagerWithHostnameChecking(validator, new DisabledNameMismatchCallback());
     }
 
     @Override