Can i change this

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain

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?

I'm not sure. Probably not.

What do you want to change and why?


Just want to change info "Organisation" name. On screenshot thats not my domain but i would like to change on mine. So can I?

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.


You need an OV certificate to put something in that field, per section of the CA/B baseline requirements.

Let's Encrypt only issues DV certificates.


how can i get it?

You cannot get it from Let's Encrypt.

You can buy one from a commercial CA.

But you probably don't need one.


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!


One might ask what happens if you send a custom CSR with the "organization" field already filled in.

I'm not going to try because I'm too lazy right now (use the staging environment if you do), but I assume one of two things will happen:

  1. Boulder will reject the CSR
  2. Boulder will ignore the "organisation" field and strip it from the certificate.

This happens :slight_smile:

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".)


90 days exactly and only 90 days, it looks like. Not more and not less. Interesting.

Is it done this way as to avoid people hardcoding durations like "30 days" when someday in the future certificates will only be valid for 12 days? :smiley:

(Probably not, durations over the maximum can still be ignored -- oh, but the renewal dates are hardcoded indeed in most clients.)

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.