OpenSSL does not accept DNs longer than 65 characters

[awesome-manuel]

Describe the bug

When the user enters a "Signer name" longer than 65 characters, openssl will fail to create a CSR

To reproduce

• Create a new signing request
• Invite user with a long name and long mail address by mail
• LibreSign will put Prename Surname (andalongemailaddress@averylongdomain.name) into the "Signer name" field by default
• Finalize the request
• As invited user try to sign the document
• LibreSign fails silently (just does not perform the signature, but does not show any error)
• In the Nextcloud protocol look for openssl_csr_new(): dn: add_entry_by_NID 13 -&gt

Expected behavior

LibreSign should limit the number of characters in "Signer name" to 65

Screenshots

No response

Environment information

• OS: Docker
• LibreSign Version 11.4.1

Additional context

No response

[vitormattos]

Thanks for reporting this!

The root cause is the Common Name (CN) attribute in the certificate request.
According to RFC 5280, the CN must not exceed 64 characters. When LibreSign builds the CSR, it uses the Nextcloud display name or the "Signer name" entered by who requested to sign, which sometimes goes beyond this limit. OpenSSL then fails silently.

We are going to improve this in two ways:

• When the certificate is self-generated with password: LibreSign will truncate the Common Name to 64 characters to stay compliant.
• When the certificate is generated without password: LibreSign will enforce a maximum of 64 characters in the input field, with a clear error message in case the value is too long.

This way, LibreSign will always stay compliant with the RFC and avoid the silent failure.

[awesome-manuel]

Thanks for your fast reply. Please verify that it's actually the length of the "Signer name" (I also found the limit in the RFC). It could also be the length of the concatenated CSR names, though I found no reference for such a limit.

[vitormattos]

The critical point is that when the Common Name comes from the system (your scenario), the safest solution for the signer is to truncate it to 64 characters.

We see some possible approaches here:

1. Quick and easy: just truncate silently and proceed;
2. More explicit: add a log entry in Nextcloud indicating that the CN was truncated;
3. More user-friendly (but more complex): notify the requester that the CN was truncated to 64 characters.

Which approach do you think would be best?

[awesome-manuel]

In my particular case the value is pre-filled by the system, but the user still has the possibility to change it before it's used ("Signer name" field when the signing request is created in Nextcloud). For this, the input field should be limited or checked before it can be sent.

If the value is really just generated internally, it should 1) be logged into the Nextcloud protocol with a meaningful message and 2) if the signing process still fails, the user should at least be notified, that something went wrong instead of silently skipping the process.

[vitormattos]

2. if the signing process still fails, the user should at least be notified, that something went wrong instead of silently skipping the process.

Limited to 64 chars, don't will fail

[awesome-manuel]

2. if the signing process still fails, the user should at least be notified, that something went wrong instead of silently skipping the process.

Limited to 64 chars, don't will fail

Not because of this, but it might also fail for other reasons. The problem is, that the UI does not check the return code of the HTTP request. In case of some 4xx or 5xx it should display a failure message.

[vitormattos]

Good point! Follow some points to fix:

• Handle error when run openssl_csr_new
  • chore: handle error and cover with tests #5487
• Add a maxlength at frontend to prevent send a name bigger than 64 chars
  • fix: add maxlength #5540
• Validate at backend to prevent names bigger than 64 chars
• Consider at frontend the error that is sent by API.