I am the author, I wanted to publish it myself, I didn't expect you had already published it. Thank you very much.
Encountered quite a few problems during the deployment, mainly related to HTTPS certificates.
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
Just to expand on this, commonName is not at all required in certificates and is basically deprecated/legacy
Letsencrypt does not require you to set it, just subject alternate names, which can be up to 255 characters, but some providers require it for no reason
To further expand, commonName is only deprecated for SSL/TLS server certificates. It is, for example, mandatory for CA certificates and code signing certificates.
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID). If
the client chooses to compare a reference identifier of type CN-ID
against that string, it MUST follow the comparison rules for the DNS
domain name portion of an identifier of type DNS-ID, SRV-ID, or
URI-ID, as described under Section 6.4.1, Section 6.4.2, and
Section 6.4.3.
9.2.2 Subject Distinguished Name Fields
a. Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address
or Fully-Qualified Domain Name that is one of the values contained
in the Certificate’s subjectAltName extension (see Section 9.2.1).
> Registrants are required to certify that they meet the following eligibility requirements when registering a .NGO or .ONG domain name:
> 1. Focused on acting in the public interest. [...] work for the good of humankind and/or the preservation of the planet
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
> 1. Focused on acting in the public interest. [...] work for the good of humankind and/or the preservation of the planet
Operating a publicly available lengthening service is in the public interest and is working for the good of all humans. I used to use hugeurl, but it's no longer in service.
> 5. Active Organizations. Members of the .NGO and .ONG community are actively pursuing their missions on a regular basis.
This is an active organization, pursing a mission of longer urls for the good of all. Maybe this sounds frivolous, but there's a lot of frivolous but chartered 501(c)(3)s, and the requirements doesn't specifically require a registrant to be registered as a non-profit or charity or similar (although such a registration is likely to satisfy an audit, tax records showing a lack of profits/retained earnings may be sufficient)
> 6. Structured. Members of the .NGO and .ONG community, whether large or small, operate in a structured manner (e.g., under bylaws, codes of conduct, organizational standards, or other governance structures.)
We don't have evidence of how it's operated. Many organizations operate websites without publishing their bylaws. Although, I'll grant that circumstantial evidence seems to be that it's operated by an individual.
The GitHub repo linked from the page is owned by an individual (not any kind of structured NGO that would be eligible for this), and they set the location field on their GitHub profile to "NanJing,China" (suggesting that they are located in China).
My first impression was: "What in the QA is this? I wonder what this breaks?"
> because they used the domain name as the commonName
Understandable, but that's old-school, right? I'm pretty sure the x.509 extensions for SAN cover this now, and I'm kind of surprised that CA's are sticking to the old way of doing this.
Encountered quite a few problems during the deployment, mainly related to HTTPS certificates.
The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.
This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.
Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.
Related certificates can be viewed at https://crt.sh/?q=looooooooooooooooooooooooooooooooooooooooo...