Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:bromine.me
I ran this command:just asking
It produced this output:nothing
The operating system my web server runs on is (include version): apache2
My hosting provider, if applicable, is:hostinger
I can login to a root shell on my machine (yes or no, or I don't know):can
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): latest one
hi guys, can i somehow change this info?
Your website is behind Cloudflare and they almost certainly controle the certificate. So no, probably nothing you can do about that. Unless you'd give up Cloudflare. Or pay Cloudflare a certain fee so you can setup your own certificate with them.
Agreed with @Osiris and @9peppe—you can get your Organization as part of your certificate if you want, but normally only with paid certificate authorities and paid hosting/CDN plans. Roughly speaking, this is because verifying your identity offline via documentation, as well as installing custom certificates in a hosting or CDN environment, can be labor-intensive processes which are harder to provide free of charge.
Let's Encrypt's services can be free of charge because all of the validation is completely automated, allowing more than 1,000,000 2,000,000 new certificates to be issued per day. That wouldn't be compatible with human review of identity documentation, so that feature isn't offered by Let's Encrypt.
It's also not clear that many end users of web sites are accustomed to checking for this information. Browsers have not made it super-easy to find and have even tended to de-emphasize it over time. So, most people may never notice whether an organization's legal identity is verified as part of a certificate or not. But if you care about it, you can definitely pay for that as a paid product from a paid CA service!
Boulder just verifies the signature of the CSR and extracts the required info from the CSR, ignoring the rest. You can even send a CSR requesting a cert with a lifetime of 365 days, but but Boulder still issues a cert with a lifetime of just 90 days.
You can see that here:
Only the public key, common name, SAN hostnames and the must staple extension are extracted from the CSR.
The theory behind this, as explained by some of the Boulder developers in the past, is that a certificate authority should not include any information in a certificate whose correctness the authority cannot confirm for itself (because the certificate can be considered as an assertion or statement by the certificate authority, confirming that the details in it are correct).
So while you can definitely request any kind of certificate you want from Let's Encrypt (or other CAs) via a CSR file, the CAs are not allowed to issue a certificate with those same details, unless they have a way of confirming that the details are right.
(It should also not include values whose meaning it doesn't understand, so if you define an X.509 extension with a HIMOM attribute and request a certificate with HIMOM = "Hi, mom!", the CA should also say "I don't know what that means to parties consuming the certificate, and so I don't know how to confirm if it matches what they expect, so I won't include that".)
