View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001539 | Main CAcert Website | certificate issuing | public | 2022-03-25 21:15 | 2022-03-27 20:15 |
| Reporter | Ted | Assigned To | Ted | ||
| Priority | high | Severity | major | Reproducibility | N/A |
| Status | needs testing | Resolution | open | ||
| Summary | 0001539: Implement an emergency workaround for 0000769 | ||||
| Description | I'm splitting this off from 0000769 so we can do the usual change documentation for the emergency workaround, since 0000769 will probably need several additional code changes... Note that in the git repositories bug-769 is used for changes concerning this bug. At least until we find a reason to create a specific branch for this. ;-) | ||||
| Tags | No tags attached. | ||||
| Reviewed by | Ted | ||||
| Test Instructions | |||||
|
|
The changes from the pull request should now be active on the testserver https://test.cacert.org @alkas can you try to request a certificate with non ISO-8859-1 characters and tell us what happens? |
|
|
The certificate was issued, no problems encountered. The cert "Ale? Kastner" ("?"="ě") can login to the testserver. See the cert attached. Possibly Wacław Schiller should perform the test with his original name. (? - can stop the signer) alkas@volny.cz_J5BC7.crt (1,992 bytes)
-----BEGIN CERTIFICATE----- MIIFkzCCA3ugAwIBAgICW8cwDQYJKoZIhvcNAQELBQAwgZIxCzAJBgNVBAYTAkNI MQ8wDQYDVQQIDAZHZW5ldmExDzANBgNVBAcMBkdlbmV2YTEeMBwGA1UECgwVQ0Fj ZXJ0IEluYyAqKipURVNUKioqMR0wGwYDVQQLDBRUZXN0IGFuZCBEZXZlbG9wbWVu dDEiMCAGA1UEAwwZQ0FjZXJ0IFRlc3RzZXJ2ZXIgQ2xhc3MgMzAeFw0yMjAzMjYw OTE1MTZaFw0yNDAzMjUwOTE1MTZaMDcxFjAUBgNVBAMMDUFsZcKaIEthc3RuZXIx HTAbBgkqhkiG9w0BCQEWDmFsa2FzQHZvbG55LmN6MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEApN5jj0msSp4yqe17amkKukErac1lydK2gE9p0sZC5exb 1cK8kbSSGrBWYmznKLCBQkoQ8OMy7uT8eALhR5HGjcVqw5c2Ikm6P4pHo3YM8JeB R1vuJKOoJ1s6C0MD1FevsuRE3WWZUtED5hlYPIisGkD3ATe3c9giZbXquvqrbDD9 hn8epj2I8QB+EefmmcLQaCTk7nRHYdfZDhiQT2PXmZ8je/1SEhNyDfC+krfW7TQF sF818wBWSTh7nYoVou/+3XNCLVYjAAX/7UxQHBtJ/e2YbYz/nQh2el5ArfJSnKRa 3IJ06oDPAfnc2ekqlrfsUZnlFGvPc9FPHKQCOACB0QIDAQABo4IBSzCCAUcwDAYD VR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRp ZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5v cmcwDgYDVR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcD AgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEB BCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA+BgNVHR8E NzA1MDOgMaAvhi1odHRwOi8vdGVzdC5jYWNlcnQub3JnL3Rlc3QtY2xhc3MzLXJl dm9rZS5jcmwwGQYDVR0RBBIwEIEOYWxrYXNAdm9sbnkuY3owDQYJKoZIhvcNAQEL BQADggIBAJHjPTMUZHObihlF0QC1Hpo+/bq9yByxvSq6HkgdaTCS7n85FVSl36z5 HAPfn5FO69T6LWnfMmFTkDmZrHGlBDTa35v9OWgccBpzd5Ix9ZCkC0Wx31GCAWOr p9MJaYQiBkEcbjxIdVejp9wK01j4wbG96TpFfxMSMBm9LfW5q3lCs5Cm0WGdtmAS zNjUOaxXb/48OE3cwlWaG7K/698HzdA1xDhQKTkj7xRtICCc0j3KsJFTSRs08Drj DNvMsaBbB3W0xw3IaHyD98OELwog5Vu7oxSwXiTc2f6pwL6NEpIr/kr2Hy7sT/YC ACE1T1ohCkeUz4fQz7zHmv0ro19DUYzyOd5MKUAyWILCkYr3BbVCKwjqbZGlDtq0 qSFqal6QjOIOz/n3sPQ+RWRT4JuPlzPKo9q6S0H35oZon2Uc8BJhVSq4Pd0E4vZH EHaNsoJBUC6Bkx8ZF7VbgVo6oauvMTMAaRZNDayIxeH7fohumLozUGQOYqPRaFbf jWbpVWiH/X/5F+nXO1pSksY4XC538Gwp7+EbQiIGCFCYJmPDoG/Ev2pbzx658/2W vJrUnBu8E8blfr+JpCXWWMm/TRuDY+xmlMyq8vc8Zbxi2kHy3MlktdNRjVFORnKQ 6lh1Sjw4kqd+B3qWHqFS/k+u9wYHb7dDcBDvfn4Mq8v0HjnwdSDI -----END CERTIFICATE----- |
|
|
Thank you Aleš, but it looks like I'm wrong in assuming that your name has also provoked the error, maybe because your first name is stored "directly" in the database table (no HTML encoding)? I now tried the more difficult name "Lech Wałęsa", which uses two of the more "notorious" polish characters. This one got stored in the database HTML encoded as "Wałęsa". When I requested a certificate containing that name I got a result containing Subject: CN = "Lech Wałęsa", emailAddress = lech@convey.de (openssl x509 -text shows it in HTML encoding, looks like Mantis does not quote them...) Though this may not conform ASN specification, this is what I'd expect from the current setup, where the name is stored HTML encoded. In comparison my certificate includes Subject: CN = Bernhard Fr\C3\B6hlich, emailAddress = ted@convey.de, emailAddress = froehlich@convey.de which is (correct?) UTF-8, while your certificate has Subject: CN = Ale\C2\9A Kastner, emailAddress = alkas@volny.cz which is probably not correct UTF-8 (š would be \C5\A1, wheres ě should be \C4\9B...). I'll now rollback the change and try if I can provoke the signer "crash" then. |
|
|
lech@convey.de.crt (2,004 bytes)
-----BEGIN CERTIFICATE----- MIIFmzCCA4OgAwIBAgICW8gwDQYJKoZIhvcNAQELBQAwgZIxCzAJBgNVBAYTAkNI MQ8wDQYDVQQIDAZHZW5ldmExDzANBgNVBAcMBkdlbmV2YTEeMBwGA1UECgwVQ0Fj ZXJ0IEluYyAqKipURVNUKioqMR0wGwYDVQQLDBRUZXN0IGFuZCBEZXZlbG9wbWVu dDEiMCAGA1UEAwwZQ0FjZXJ0IFRlc3RzZXJ2ZXIgQ2xhc3MgMzAeFw0yMjAzMjYx OTE5MTZaFw0yNDAzMjUxOTE5MTZaMD8xHjAcBgNVBAMMFUxlY2ggV2EmIzMyMjsm IzI4MTtzYTEdMBsGCSqGSIb3DQEJARYObGVjaEBjb252ZXkuZGUwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/WLmV7/qedPcCyHhQrXVgg/Wl6MoQ/5XR w8RWQyonj9ZlyGXWKhVvAbnRZVb/kb9T9Ofr5/tt4+zUdXuR9l5/AheZqWXYvY80 /TRnwAwj1bM2AHgRR3LqsOyEy9WpH6wcwu6jsRFA8I8/9YwGJhei/+ze3LPDFxNp aKGd/gQwXQhugnc2l3Ce2BkqPMAW458hj8rCn3E0F8o5k5XSOk3oqCasbi5shaDN ZC0LyrVfVLTuHUv2TGjNFXEpfJxF6bww55ccckHzkCGRcQbfUcS3ciUB2jFRfG1s +KbWrESU7XCNFtWPyewb/yf/B+q7Su1zCSxoRFncNaByuh4js9OHAgMBAAGjggFL MIIBRzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBv d24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQG CCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYI KwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3Jn MD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly90ZXN0LmNhY2VydC5vcmcvdGVzdC1j bGFzczMtcmV2b2tlLmNybDAZBgNVHREEEjAQgQ5sZWNoQGNvbnZleS5kZTANBgkq hkiG9w0BAQsFAAOCAgEAaQXLTkgu9uxKgabfvhRbh2V+efIGe6BdrWbv/gxLwxN2 zLzx6mtvtLvqb33N3acX67h87OPay9Gekx+KxlxsIa0o4oHXtsD3EA8/HBelIlq7 zQQPFfplXhihMb1ZiADNOm6RwrgSmZABXswocvNYMGSn9jteX4f63wkiPbU9s2Ll Cs2gLuVUi3/hxv9RFJrW5dm+oYIez7qyB/Xc2wngtNywG6gA1QX2ryu/3vDPDyqa 0HzJcVqWNTrIWcPZf7OnQfyu/m3j4LUSSW2Gef2OuqnVOFYojT+zmYyfccewMGdc /E/JpLeI3yRIS1lrmngD88WTcW5DrK9xXVmKMlfDa+mZ/DBFsQBf/Ehsd366EgqS /DPxPUiPjVLLSN1Bq+yXQPHbq6+7xkd2KrhmR8WyFImFPsWA2G/xY6ENQrpPsqjD eeN+3JdGZC9FsgtV4buwhFg1YLq2YkV7Hm+fqED12aUn1EJiSbOTZBA6oWVBG7gc ksHQJCFXFwWRpWIVGbrMk7H0eTgPHNtnjrSeX4GZ2hMJ/F3GkOhpR3vtemDboD+6 sh2COTD7tSfqfsfJaxeiK3AF71EqPuoP6qvzfqDo9ileEgRp5MDYEXuHzsprHp63 TqCWN5ubu0t8BKHltYkiLFT2Ke37Gaxz09OL9AFFAo7Gvhz5FM/aGBYLNtchfuw= -----END CERTIFICATE----- |
|
|
The same both in Windows and Linux Ubuntu: displaying in account is OK, displaying of an issued cert - white space or a square. \C2\9A is 2-byte 9A code taken from Wndows ANSI CP-1250, no conversion to Unicode. |
|
|
In a session with Jan and Dirk I now find out what this workaround should do: It checks the subject and SAN of the internally created CSR (which is not the same as the uploaded CSR) for "evil characters". If the server.pl receives any of these "evil characters" it will terminate, but the client.pl is not notified, so it will continue to send the CSR (and therefor teminating the server.pl), which effectively blocks all certificate issuing. Some "evil characters" have already been handled before, this workaround additionaly checks for the hash "#", which is also considered "evil" by server.pl So, with this workaround, CSR for names containing hash characters, which most prominently includes all HTML encoded characters (most characters outside ISO-8859-1), are not sent to the signing server. |
|
|
Also in the session with Jan and Dirk we found a bug in the pull request and fixed it. Now, if I request a certificate for "Lech Wałęsa" the certificate remains in the list of client certificates with status "Pending", but I still can issue certificates for my name. This is by far not the ideal solution, but it is not worse than before and saves us support work. The code review which went with the tests, is a PASS |
|
|
I would appreceate an additional test reports from someone else. Please create a new account for a name containing some greek, kyrillic, japanese character(s), or somply add a hash character to the name. Certificate issuing should not be work for these names. Then create an account wit a name from ISO-8859-1 characters (or use an existing one), certificate issuing should work for them. @alkas: The š character is some special case. It is stored without HTML encoding, though it is not part of ISO-8859-1. I indeed do not understand completely what is happening there, but it should not count as "evil character", so you probably can issue certificates on the testserver as before. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-03-25 21:15 | Ted | New Issue | |
| 2022-03-25 21:15 | Ted | Assigned To | => Ted |
| 2022-03-25 21:15 | Ted | Relationship added | child of 0000769 |
| 2022-03-25 21:16 | Ted | Status | new => needs review & testing |
| 2022-03-25 22:29 | Ted | Note Added: 0006105 | |
| 2022-03-25 22:29 | Ted | Assigned To | Ted => alkas |
| 2022-03-26 22:54 | alkas | Note Added: 0006106 | |
| 2022-03-26 22:54 | alkas | File Added: alkas@volny.cz_J5BC7.crt | |
| 2022-03-27 12:00 | Ted | Note Added: 0006107 | |
| 2022-03-27 12:02 | Ted | Note Edited: 0006107 | |
| 2022-03-27 12:02 | Ted | Note Edited: 0006107 | |
| 2022-03-27 12:03 | Ted | Note Edited: 0006107 | |
| 2022-03-27 12:03 | Ted | Note Edited: 0006107 | |
| 2022-03-27 12:04 | Ted | Note Edited: 0006107 | |
| 2022-03-27 12:04 | Ted | Note Added: 0006108 | |
| 2022-03-27 12:04 | Ted | File Added: lech@convey.de.crt | |
| 2022-03-27 12:08 | Ted | Assigned To | alkas => Ted |
| 2022-03-27 17:14 | alkas | Note Added: 0006109 | |
| 2022-03-27 19:56 | Ted | Note Added: 0006110 | |
| 2022-03-27 20:03 | Ted | Note Added: 0006111 | |
| 2022-03-27 20:04 | Ted | Reviewed by | => Ted |
| 2022-03-27 20:04 | Ted | Status | needs review & testing => needs testing |
| 2022-03-27 20:14 | Ted | Note Added: 0006112 | |
| 2022-03-27 20:15 | Ted | Note Edited: 0006112 |
