Unable to link certificate with special characters in the subject

[vokac]

I'm not able to link certificate with this subject using IAM web interface that shows following dialog but nothing gets added by pushing "Link" button. It is also interesting that login page displays certificate subject differently .

I'm not even able to add this certificate subject directly with API using

> PATCH /scim/Users/266d17cd-3f59-6093-b3ab-cc65afa33850 HTTP/1.1
> Host: atlas-auth.web.cern.ch
> Accept-Encoding: identity
> Content-type: application/scim+json
> Authorization: Bearer secret
> Content-Length: 582
>
> {"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "operations": [{"op": "add", "path": "certificates", "value": {"urn:indigo-dc:scim:schemas:IndigoUser": {"certificates": [{"label": "cert-1", "subjectDn": "emailAddress=petr.vokac@fjfi.cvut.cz,CN=Petr Vok\\\\C3\\\\A1\\\\C4\\\\8D,C=CZ,L=Praha 6 - Dejvice,ST=Praha\\\\, Hlavn\\\\C3\\\\AD m\\\\C4\\\\9Bsto,street=Jugosl\\\\C3\\\\A1vsk\\\\C3\\\\BDch partyz\\\\C3\\\\A1n\\\\C5\\\\AF 1580/3,O=\\\\C4\\\\8Cesk\\\\C3\\\\A9 vysok\\\\C3\\\\A9 u\\\\C4\\\\8Den\\\\C3\\\\AD technick\\\\C3\\\\A9 v Praze,postalCode=160 00", "issuerDn": "CN=GEANT Personal CA 4,O=GEANT Vereniging,C=NL"}]}}}]}

< HTTP/1.1 400 Bad Request
< Server: nginx/1.17.9
< Date: Thu, 24 Nov 2022 23:44:27 GMT
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
< X-Application-Context: INDIGO IAM:mysql,flyway-repair,prod,oidc,cern,registration,wlcg-scopes:8080

[giacomini]

Are non-ascii characters allowed? see https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoIdealwithnon-ASCIIcharactersforIGTFcertificates?

[giacomini]

I've found this https://ggus.eu/index.php?mode=ticket_info&ticket_id=152981. In particular, update#5 cites https://www.ogf.org/documents/GFD.125.pdf as forbidding non-ASCII characters in IGTF certificates. I'm checking if that document is still relevant.

[msalle]

Hi all, the problem is that it's GEANT Personal CA 4 certificate, not the IGTF-MICS version (you should be able to choose that when getting a certificate from the GEANT TCS). For the personal UTF-8 is fine, for IGTF it's not. The best reference is https://www.ogf.org/documents/GFD.225.pdf as referred to from https://www.eugridpma.org/guidelines/pkitech/ See in particular §4.3 in GFD.225

[vokac]

"solved" by secondary CERN account which can be used to issue different certificate for my second IAM account.

Our national CA operator CESNET no longer issue TCS grid certificates and it is too complicated / time consuming to get personal certificate from their own CESNET CA4 personal authority.

[vokac]

Still, it would be nice if IAM prints error while trying to link "bad" certificate and not just blank page. Actually, page is not empty and it contains, e.g.

Internal Exception: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Data too long for column 'subject_dn' at row 1
Error Code: 1406
Call: INSERT INTO iam_x509_cert (CERTIFICATE, creation_time, issuer_dn, LABEL, last_update_time, is_primary, subject_dn, account_id, proxy_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
    bind => [9 parameters bound]
Query: InsertObjectQuery(IamX509Certificate [label=cert-1, subjectDn=emailAddress=petr.vokac@fjfi.cvut.cz,CN=Petr Vok\C3\A1\C4\8D,C=CZ,L=Praha 6 - Dejvice,ST=Praha\, Hlavn\C3\AD m\C4\9Bsto,street=Jugosl\C3\A1vsk\C3\BDch partyz\C3\A1n\C5\AF 1580/3,O=\C4\8Cesk\C3\A9 vysok\C3\A9 u\C4\8Den\C3\AD technick\C3\A9 v Praze,postalCode=160 00, issuerDn=CN=GEANT Personal CA 4,O=GEANT Vereniging,C=NL, certificate=-----BEGIN CERTIFICATE-----
MIIGhzCCBG+gAwIBAgIRAO2hGoohcsPYKVa/eATH8VMwDQYJKoZIhvcNAQEMBQAw
RjELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxHDAaBgNV
BAMTE0dFQU5UIFBlcnNvbmFsIENBIDQwHhcNMjEwNDI3MDAwMDAwWhcNMjQwNDI2
MjM1OTU5WjCB+zEPMA0GA1UEERMGMTYwIDAwMTMwMQYDVQQKDCrEjGVza8OpIHZ5
c29rw6kgdcSNZW7DrSB0ZWNobmlja8OpIHYgUHJhemUxKzApBgNVBAkMIkp1Z29z
bMOhdnNrw71jaCBwYXJ0eXrDoW7FryAxNTgwLzMxHjAcBgNVBAgMFVByYWhhLCBI
bGF2bsOtIG3Em3N0bzEaMBgGA1UEBxMRUHJhaGEgNiAtIERlanZpY2UxCzAJBgNV
BAYTAkNaMRUwEwYDVQQDDAxQZXRyIFZva8OhxI0xJjAkBgkqhkiG9w0BCQEWF3Bl
dHIudm9rYWNAZmpmaS5jdnV0LmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAiJobSEhRg8G+fx+DgtKPYdzJ0Auo7HU27Noq8LZqntscmW772V5/Sa7g
6C3wTlyHyMc6i9/J0a8fa2SAxTtwu2MWrMb1kCkqeZ8mdY4ufVxH7wkdwUIJEqap
il+koXAYTv60z7NPP769rWQqibiM/zu5LEAVukzjjj9iQ9AKMgYycsa+v8bgEYRe
J4TX6K4gCnZ+VBRBT2GLOGCiNTm0mjHI2IIQ5Ec1htKak4oQcHMJijdujk0Qz4+m
K0I2egMNvBWBo+l2jbJ6KmdTcVv8NRmFD22DcZ81/aY93PTNv+pn5SKV7JW9kS1m
OnIlDJNPFEYH+OynYKFIWmDm91cxyQIDAQABo4IBuDCCAbQwHwYDVR0jBBgwFoAU
aQChxyFY+ODFGyCwCt2nUb8T2eQwHQYDVR0OBBYEFCvihoHIlgcvNlQ725Xqyj+d
zl8JMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsG
AQUFBwMEBggrBgEFBQcDAjA/BgNVHSAEODA2MDQGCysGAQQBsjEBAgJPMCUwIwYI
KwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMEIGA1UdHwQ7MDkwN6A1
oDOGMWh0dHA6Ly9HRUFOVC5jcmwuc2VjdGlnby5jb20vR0VBTlRQZXJzb25hbENB
NC5jcmwweAYIKwYBBQUHAQEEbDBqMD0GCCsGAQUFBzAChjFodHRwOi8vR0VBTlQu
Y3J0LnNlY3RpZ28uY29tL0dFQU5UUGVyc29uYWxDQTQuY3J0MCkGCCsGAQUFBzAB
hh1odHRwOi8vR0VBTlQub2NzcC5zZWN0aWdvLmNvbTA2BgNVHREELzAtgRJQZXRy
LlZva2FjQGN2dXQuY3qBF3BldHIudm9rYWNAZmpmaS5jdnV0LmN6MA0GCSqGSIb3
DQEBDAUAA4ICAQAi/5orca8pL41lHnoiiOr63Y37i2eJkx/uvTC8JQ2WzeTCcCRn
TF97Qvhfg3dvKywESFAwysOHaqRX4YKQfw0vxan1rR/yZrXz87G9VFVLQDQOZIFU
i8YUZX7rmgw81I34n21o1o1lsS+CkppdLjsU4M+JNwLZb9ERJfVYN4ysinZyqE6Q
LvN7QjXZfi4Vr097BNXz+qicrCc6JNSyKGtD8WHUvV1wTQRi52koQcVumkMFaRri
9OIbd+luU9NVSLecjDFCqvbY1iqM7yAUXtiYSPA6PmxEgdMMPLfdva/dak5AtIy/
hleAz7kyR21UMz9pPrFt71wkqE3UnU/vSCUeDEuGhXekcbkKSZhYEFjWXT2Em7Fu
e+koCI1awLDYvtGBUPMQ5qT31c0V8WtDXJEdVKH622Z8JXZm53B3oEF0XZHayI03
zsMcoeDn9ZBbxFiIzmqxafv41Vchhl9ExhzksRa5jttuOD9/vnV9E6KOiiYP4pBH
DxPDm1+oxOHVJVF6J5/scgLsE8yYrl0amAaG3shbk8YBItyeGl9MEOOsXvEYo6aM
Cmdf1mQW4m0LZKuf5LGLj4op5jihDr9+dJoQt67AOv/z1r7lR04FlMdu6VKItTty
PiIFrsyoNgMUP+J4DMphB/gCIahHYsA47P/2GxtG1F8mgdlVc3yWZBTOqg==
-----END CERTIFICATE-----, primary=true, creationTime=Mon Nov 28 11:41:57 CET 2022, lastUpdateTime=Mon Nov 28 11:41:57 CET 2022])"

[msalle]

I agree a clear error message would definitely be good. Also, if it is IGTF only, it should not have the GEANT Personal CA 4 configured as acceptable CA, but only the IGTF bundles.

[giacomini]

From the output of openssl s_client, I see only IGTF CAs. I agree that the messages should be more informative.

[msalle]

Ah, right. The client is probably sending both the EEC and the "GEANT Personal CA 4" certificates. The latter (see https://crt.sh/?caid=160144) is issued by the same CA as the "GEANT eScience Personal CA 4" (see https://crt.sh/?caid=160134), hence the chain is still accepted since that common parent is in the IGTF distribution (ca_USERTrustRSACertificationAuthority-1.117-1). There isn't much one can do about that.