NewOrder request included invalid non-DNS type identifier: type "ip",

Hi I m trying to get a certificate from a CSR that has a private IP
with the below command but the certbot it fails with this error : NewOrder request included invalid non-DNS type identifier: type "ip", value "10.0.0.113"

any hints please ?

My domain is: okv1.tse-dataservices.tk

I ran this command: sudo certbot -v certonly
--agree-tos
--email XXX@yahoo.com
--preferred-challenges dns
--manual
--preferred-challenges=dns
-d okv1.tse-dataservices.tk
--server https://acme-v02.api.letsencrypt.org/directory
--csr ./okv.csr

It produced this output:
Plugins selected: Authenticator manual, Installer None
Requesting a certificate for okv1.tse-dataservices.tk
An unexpected error occurred:
The request message was malformed :: NewOrder request included invalid non-DNS type identifier: type "ip", value "10.0.0.113"
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Two things:

  • Let's Encrypt does not issue certificates for IP addresses (and Certbot doesn't support it either);
  • Even with CAs which do issue certificates for IP addresses (publicly trusted CAs that is), you cannot get a certificate for a private IP address: this is simply not allowed by the CA/Browser Forum baseline requirements.
3 Likes

Please redo the CSR file

and leave out the IP [only use the name]

OR

don't use any CSR file.

1 Like

Best solution here is to set up a DNS entry, like local.example.org (where example.org is your public domain) which, if the server 10.0.0.113 is not to be publicy available, is aimed at your current public web server or similiar.
Then in your firewall, you add a DNS override for local.example.org --> 10.0.0.113
This will then override so local.example.org resoves to 10.0.0.113 but only if a client behind the firewall asks for it. Otherwise, it will return the IP of your public server, where validations against letsencrypt can be done.

another way, is to tell your DNS server to use a separate zonefile for *.example.org if the host requesting it has a client IP of 10.*.*.*

In this way, you will be able to gain a certificate for the domain local.example.org, but still have it resolve to 10.0.0.113 inside your own network.

If the server in question already have a public domain name, just override your firewall DNS so it returns 10.0.0.113 for local queries of that domain name. Or tell your DNS server to do it in config.

@sebastiannielsen
I don't see how any of that will remove the IP from the CSR [which is the real problem].
OR
Was that step somehow implied?

1 Like

What I have understanded, the OP wanted to have a certificate for his private IP adress aswell, and I proposed alternative solutions to that, that would effectively gain a certificate for the site while still directing the traffic to the local IP (in case using the local IP gives administrative access to the site or if the local site isn't public or available to the public) by using a multi-homed DNS or a firewall DNS override to have local.example.org to resolve to the public IP externally and local IP internally.

I really do understand your solution.
But they are trying to get a cert with an IP in it - that can't happen (not yet anyway - not from LE).
Step #1: Remove IP from CSR (get cert, use cert)

If they can't figure out how to access that cert (locally), then we can move towards a solution for that other problem (as you have provided) as yet unexperienced nor any help for it requested.

I think @sebastiannielsen is suggesting a split-horizon DNS setup.

A prerequisite is of course that the host should be reachable from the world wide web somehow. Not sure if that's feasable in the setup of OP.

1 Like

A solution to a problem that hasn't been experienced/described (yet).

Exactly, thats what I suggested. And no, the host in question doesn't need to be publicity reachable, as the split-horizon DNS doesn't even need to return a IP that points to the same physical server for public respective private clients, meaning the host that is actually getting the certificate installed, doesn't need to be publicity reacable, as long as there is another public server that can perform the validation for the internal server.

I interpreted OP's question as "I want a certificate for the private IP 10.0.0.113, how can I do it" and as it isn't possible, I proposed alternative solutions which would fullfill the same role for OP (directing internal traffic against the private IP of the site instead while still presenting a valid HTTPS certificate to the clients)

1 Like

That's technically possible, however, usually this requires non-standard setups to transfer either the validation token to the server actually serving the token file or some way to transfer the certificate and private key securely back to the host actually requiring the certificate.

It's probably way more easy to implement the dns-01 challenge I think. E.g., using acme-dns or similar solutions. Which by the way is almost the same global idea you're proposing :stuck_out_tongue:

Not entirely if you read the request from OP very strictly. OP seems to be wanting a certificate for literally the IP address, not just for a hostname which returns a private IP address. Let's Encrypt doesn't issue certificates for IP addresses at all, even if it was a publicly routable IP address.

2 Likes

If one were to read your solution, one might think his problem can be completely solved by DNS tricks alone. [which is not the case]
You jumped straight to Step #2 [skipping Step #1 altogether] and without ensuring the OP even requires the IP in the cert.

1 Like

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