I'm learning about X509 certs used in client-cert authentication to https endpoints. I have a nice Python script that checks many facets of the client-cert.

Is there any validation that can be performed from a reverse DNS lookup on the client IP?


  • Client makes request to my https endpoint
  • I grab the IP address from request header
  • Check that it is a valid IP4 (will check IPV6 at some point) address using the Python socket.inet_aton() function
  • Then finally perform a reverse dns lookup using the socket.gethostbyaddr() function

The results look something like:

('111-111-111-11.somecompany.com', [], [''])

These results do not always contain the Subject Alt/Common Name (which I'd like to check here to ensure the request is coming from the same domain as the certificate is granted for).

Is there any other meaningful client-cert validation I can do with this info?


  • In case it helps, below is what I'm wondering
  • If I have the IP of request AND the Subject Common Name of the certificate in the client's request
  • What checks can I perform on the IP address that would increase security?
  • I can't tell whether checking the request IP against the IP resolved from DNS lookup would be useful 100% of the time OR
  • Whether I should check the request IP against the reverse DNS lookup results.
  • Each test seems to yield slightly different results depending on the requestors domain.

enter image description here

1 Answer 1


About meaningful information from reverse DNS: The short answer is no, not really.

About CLIENT certificates and SERVER certificates:

Normally when you use a X.509 certificate for client validation, the client (normally a web browser) will represent a CLIENT certificate to the HTTPS endpoint, much like the HTTPS endpoint will represent its own certificate to the client. The server can then choose to trust the client certificate based on if it is issued by a trusted authority for the server. This might be a certificate authority (CA) belonging to the organization that runs the server, or a CA that is commonly trusted by most devices.

What you seem to be doing is looking at the SERVER certificate at the HTTPS endpoint for the reverse DNS that the client IP address points to. This is normally not something that you would do. But for the sake of your question, I will continue down this path to provide you with what you can find:

Making sure a reverse DNS name can be trusted

First of all you must be aware of that a reverse DNS name can point to ANY DNS name that the owner of the IP would like to point it to.

In order to be able to trust the reverse DNS name of an IP address, you will also need to resolve the reverse DNS name to an IP address and compare it to the client IP to see if they match. If they do not, the name cannot be trusted.

Imposter example:

The owner of IP address sets its reverse DNS name to yourbank.com. If you check the SSL sertificate at yourbank.com:443 it would probably be valid for yourbank.com. But yourbank.com and its valid certificate has nothing to do with the client. Resolving yourbank.com to an IP address will show that it points to another IP than the client IP, meaning that there is probably no relationship between the reverse DNS name and the client IP other than the reverse DNS name (PTR record) in the DNS zone which is controlled by the owner of the IP address. The owner in control is usually the ISP or a company with static IP address(es) from their ISP).

Common valid examples:

If you have a client IP that resolves to 44.33-pool.dyn.cable.someisp.net and the name 44.33-pool.dyn.cable.someisp.net resolves to you know that the name is correct. This client might be a user connected by a cable modem with a router which probably do not have any open HTTPS endpoints.

If that client is running a website at their IP address, it would probably be for another name than 44.33-pool.dyn.cable.someisp.net. Maybe something like mypersonalwebsitethatirunfromhome.com.

For a client connecting from a business location the IP address might resolve to something like lan-gw.mainoffice.somecompany.com or static-77.88.other.isp.com. They might host a webserver at this IP, or they more likely have a subnet of more IP addresses and they have another IP address for their webserver.

Other client IPs might not have any reverse DNS names at all, or they can have a name that points to a different IP address than the client, but still be related, or they are a bot that crawls the internet for indexing or looking for exploitable vulnerabilities in the web servers. These bots might have IP addresses from a cloud based IaaS network like AWS. A good bot will present its name and maybe an URL for more information in the HTTP_USER_AGENT header.

Even if the client IP address is a dedicated webserver it would probably have a reverse DNS name in the format of web94.someisp.com. The server might host www.someisp.com and several other websites accessible at the HTTPS endpoint by providing other.websites.net in the SNI of the HTTPS request.

Final thoughts for looking into the reverse DNS name of a client:

If you are lucky, the reverse DNS of the client IP might actually point to a DNS name that is related to the client IP, which you confirm by resolving the DNS name back to its IP address and compare it to the client IP, and you can validate the certificate, but all it proves is that the client IP has a webserver running with a valid server certificate for the DNS name that the IP address points to in DNS. Note that the client that is connecting to your HTTPS endpoint might be a web browser in the network behind that public IP, or it might be some malicious activity from a compromised device in their network that is making the connection to your web server.

Back to actual validation of CLIENT certificates:

If you want to trust a client you must let the client prove its identity. This can be done by a client certificate installed in the actual client software (like in a certificate storage that the browser can access). The client will present this certificate when contacting the HTTPS endpoint on your server. This certificate must be created by a certificate authority that your web server trusts. The certificate can be installed in the client automatically from a central system for device management.

If you are not using a client certificate you will need to let the client identify itself by other means, like a username and password, or a valid authentication token that can be verified by the server.

Reply to Edit 1

What are your use case scenario here? Are you running a service that requires a certificate while you are willing to accept any publicly trusted certificate, but then restrict that access only if the client is related to a certain set of domain names?

Normally you would only trust client certificates from a certain certificate authority in order to have decent control of who can gain access to your service. If your goal is to provide access to anyone in the "somecompany.com" domain without ever having anything to do with the client certificate it might not be as easy as that.

If you want to provide the service to anyone with a public certificate you should only trust the data in the client certificate itself. As you already figured out, the CN field of the client certificate might be empty. Dealing with certificates with no verifiable domain name really has no other solution than making the client change their certificate, or whitelist that specific certificate.

The IP address of the client should not be used to approve access unless you know a specific set of IP addresses that you want to allow. An IP address only says something about what infrastructure the client is coming from. It doesn't prove that they are related. Accepting any connection based on the IP address alone poses a great security risk unless you know that you really can trust any connection from that IP, which also means that you need to trust all software and all hardware in the whole network of that IP.

The top level domain associated with the reverse DNS might not have anything to do with the IP address. Lets say I own an IP and I point it to mydynamichost.dyndns.org, and using my account at DYN.com to point that hostname back to my IP address. That makes me connect from mydynamichost.dyndns.org, but I still don't own or operate on behalf of dyndns.org.

In your example where Bob connects with a certificate for bob.com, it would be just as likely that he is connecting from an IP that has a pointer for the hostname, breaking the relationship between his domain identity and network identity.

What checks can I perform on the IP address that would increase security?

You can check if the IP address is listed in any blacklist databases. You should probably reject requests from an IP address that is exceeding a certain threshold in a certain time that would be outside of normal activity.

I can't tell whether checking the request IP against the IP resolved from DNS lookup would be useful 100% of the time OR Whether I should check the request IP against the reverse DNS lookup results.

I am not sure if I understand the differences between your option a or b here. I am sure of that you should NEVER trust the reverse DNS name unless the reverse DNS name can also be resolved to the IP address of the client. I am sure that an IP address will not always have a reverse DNS name. Sometimes it might even have more than one name. The name may or may not be related to the client, but at least the client IP is listed in the DNS zone for the domain if you can resolve IP to hostname, and hostname back to the same IP.

I would still not say that it would be recommended to use the reverse DNS name or the IP address of the client for doing client authentication.

Ping me again if you need further clarification.

  • This is an excellent response with lots of useful details.Thankyou.One small point of clarity RE: "What you seem to be doing is looking at the SERVER certificate at the HTTPS endpoint for the reverse DNS that the client IP address points to." HTTP-triggered Azure Functions with "enable HTTPS" and "Client certificate mode" set to "require" are passed the Client Cert from the request itself, in a special header. (No client did not send their certificate in a header :), Azure just forwards it to my script in a header). So I'm indeed looking at the CLIENT cert. Still much of what you said applies.
    – ericOnline
    Commented Feb 17, 2021 at 17:39
  • Added an EDIT 1 in OP for some more clarity
    – ericOnline
    Commented Feb 18, 2021 at 0:03
  • Would really like to hear your input on the EDIT.
    – ericOnline
    Commented Feb 18, 2021 at 21:19
  • 1
    Reply to Edit 1 was added to my answer.
    – knowsshit
    Commented Feb 19, 2021 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .