Forum Discussion

Sonador_28_1978's avatar
Icon for Altostratus rankAltostratus
Jun 20, 2024

Problem FQDN. Certificates and URL.



We have configured a virtual server with a redirection by local traffic policy to pool configured wit a FQDN. The FQDN, of course, translate the FQDN as an IP. Which is the normal behaviour of F5. But... We need to use the FQDN to reach our page web. Not the IP. If we do that, we obtain the wrong certificate, the certif being attached to the virtual server, not to the IP, in summarize. 

So, do you know if there is any way to force the utilisation of the FQDN instead of the IP, please ? Or maybe we muse use an additionnal Irule, maybe ? We found this KB on internet :


So, here we are, today :

-On pool member added URL, it resolves automatically to IP and query to IP, where no certificate available when accessing via IP.

-Any options to avoid IP here and make it work with URL?

-This is hosted on Azure webapp.


Any help or suggestion will be really appreciated. 


Best regards,


4 Replies

  • Hello,


    Thank you all for your propositions :). They seems all interresting, for me. hmmmm I had a call this morning, after I created this topic. The application's guys seems to have a solution to fix it by doing a change on the server, side cloud. I will see if that really fix the problem.


    But I have a question, anyway. If we apply the F5's KB I mentionned, we will replace the IP by HTTP::header replace "Host" "" } (to take this example), but... the F5 will not try to replace again the "smart..." by the IP, following the configuration in the traffic policy ? I do not know if I am clear, as I am newbe on F5....


    Oh wait a second, I think I understand. Normally, it should work like that, if we apply this KB, if I am not wrong :

    1/ The request come to the F5. With the traffic policy, it will redirect the request to the IP.

    2/ In the same time it will change the Header following the "kb's" irule.

    3/ And when the request will arrive to the server, it will arrive with the good address, the good url, actually, to the server of destination, then the application web.


    All right, in first view that could be a solution. But... Here, we are in this situation : the virtual server is attached to a lot of redirections HTTP, by his traffic policy. That mean all the requests sent to the same virtual server, so the same IP, let's say, will be transformed with the new header, doesn't matter if they are originally sent to "smart..." (or anything else), no ? 


    Thanks to Paulius and Zamrooni, too. I see what you mean, Paulius. Maybe that could work too. However, Zamrooni, can you develop what you mean by " you need to inform the application team to always use relative paths in the application codes" ? Just to clarify.

  • for ideal solution, you need to inform the application team to always use relative paths in the application codes.

  • You will always receive this error when connecting via the IP and then performing the redirect. If this is not something that works for you you will need to generate a new CSR with a SAN that also includes the IP of the website in question and receive a new certificate.

  • Hi Christian,


    You have two options:

    *Force the application to redirect the request when a user type the public IP

    *Create an irule to change the IP by the URL as the post you have mentioned

    when HTTP_REQUEST { 
        if { [HTTP::host] equals "" } { 
        HTTP::header replace "Host" "" }

     hope it works.