Common Name Support in acme.crypto_util

[IdoHaritan]

@Osiris

Extra work? Sure.. Much extra work? I doubt that.. It's not a difficult patch

This change is really not difficult .
But in our environment we have our local hosted GitLab. So I can't really fork.
But I meant more like if we would like to get a new version of the original package, it will require some work to match the new version with our patched one.

@Osiris

(Note that if no domain is specified but just one or more IP address, this patch will raise an exception.. Although currently Certbot doesn't support IP addresses, so if the acme library is only used with Certbot, it shouldn't matter much..)

Thanks for that note, I know, it won't be a problem for us because we are only using Domains.

@Osiris

That said, the issue I linked above was closed automatically without an actual decision written down.. Maybe the Certbot team is open for the suggestion.

I got nothing to lose by trying to re-open this suggestion.

---

So I have 3 options to achieve the desired behavior I want:

1. Re-open the suggestion to the certbot team.
2. Modify our CA or ACME Server configuration.
3. Patch the acme package locally.

?

[Osiris]

@IdoHaritan

But in our environment we have our local hosted GitLab. So I can't really fork.

Can't GitLab import a Github repo into a new GitLab repo? Essentially forking it?

@IdoHaritan

But I meant more like if we would like to get a new version of the original package, it will require some work to match the new version with our patched one.

Yeah, that's easy with git:

git checkout -b new_feature
.. do some stuff ..
git commit

... upstream changes some stuff ...

git checkout main
git fetch --all
git merge upstream/main
git checkout new_feature
git rebase main

(Assuming you have a remote called upstream set up pointing to the actual upstream git repo.)

I have a Certbot fork with a few added features and I rebase main often enough.. When changes have been made to the code which was also modified by yourself, you'd get a conflict you'd need to resolve before continuing with the rebase, but that's often easy enough, especially with this easy patch.

[IdoHaritan]

@Osiris

Can't GitLab import a Github repo into a new GitLab repo? Essentially forking it?

Our network is totally isolated from the WWW Internet.
So we have to manually burn the package on a CD from an internet computer into and insert it into our isolated network.

@Osiris

(Assuming you have a remote called upstream set up pointing to the actual upstream git repo.)

Thanks.
That might do the trick, but I still would like to take that option as last resort.
I prefer to suggest a PR and then transfer it into our network. So newer versions won't require anything to change.
Also prefer to modify our ACME Server or CA configurations.

---

But just to make sure, this 3 options is our all options we have?

[MikeMcQ]

@IdoHaritan

But just to make sure, this 3 options is our all options we have?

Well, it all depends on time and money - like usual

1. You could look for a different ACME Client that sets the name in the CSR. And, I presume your private CA would pick it up - right?
2. You could review the --csr option in Certbot. It is fairly unfriendly and I don't think it supports Certbot auto-renew. I don't recall a legit case for needing it before. The idea is you make your own CSR and tell Certbot to send that. (I think so anyway)
3. Rework the programs that require the CN to use something different for authorization. The difficulties you are having relate to trying to support this field that was deprecated decades ago

[IdoHaritan]

@MikeMcQ

You could review the --csr option in Certbot. It is fairly unfriendly and I don't think it supports Certbot auto-renew. I don't recall a legit case for needing it before. The idea is you make your own CSR and tell Certbot to send that. (I think so anyway)

That's exactly what I did for now, at least as a temporary solution.
Since we are not using the auto-renew anyway there is no problem.

But I would still like to have this integrated in the ACME and not in our client-side python script.