Forum Discussion

mwi's avatar
mwi
Icon for Cirrus rankCirrus
Nov 25, 2024

Problem with lets encrypt and redirect after update

Hi,

we have updated our BigIP last week from 15.x to 17.1.1.4, since then we are not able to get certificates from lets encrypt, if there is the _sys_https_redirect iRule active on the Virtual Server.

 

As an example, i have for the IP 1.2.3.4 (asdf123.info) two VS with port 80 and 443, on port 80 are two iRules mapped:

lets_encrypt:

when HTTP_REQUEST {
        if {[HTTP::has_responded]} {return}

        if { not ([HTTP::path] starts_with "/.well-known/acme-challenge/") } { return }
		set token [lindex [split [HTTP::path] "/"] end]
		set response [class match -value -- $token equals acme_responses]
		if { "$response" == "" } {
			log local0. "Responding with 404 to ACME challenge $token"
			HTTP::respond 404 content "Challenge-response token not found."
		} else {
			log local0. "Responding to ACME challenge $token with response $response"
			HTTP::respond 200 content "$response" "Content-Type" "text/plain; charset=utf-8"
		}
	}

and _sys_https_redirect:

# Copyright 2003-2006, 2012-2013, 2016, 2019.  F5 Networks, Inc.  See End User License Agreement ("EULA")
# for license terms. Notwithstanding anything to the contrary in the EULA,
# Licensee may copy and modify this software product for its internal business
# purposes. Further, Licensee may upload, publish and distribute the modified
# version of the software product on devcentral.f5.com.
#
    when HTTP_REQUEST {
       HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
    }
definition-signature tJY87UPbfpgQ3TPXqXhbCAgqIJhR1MvyFxXLTX/wNqmH+XV51tNkr8HWmv4PBq8hm6w7peLKj88shG+0RiX+yAMU31n6jS9vRcg0VKNPBWLTzu3Ic8abqyyY6XYgkMel+d9Sa8x+vakcuPcAZ0dnICHQiQFePjxYUD0XKwIrbGqQb8vEcU3HHbDaLoMQry4KDnV3s1crFpWXBZBo6esIdzM/s0jYncqZBNdTmIEH3ujEunmo2Jh9MBDhwfGKy1XwCfeeZvzk8b1J+HbRk7W/vbrRUewJZDt+Z13i9u/MbneAL4QXZgtjSxU2nN4GcZjWePUIm7oxc1nz9FGeNva1xg==

 

This configuration had worked for years now, but since the update to 17.1.1.4 we get a "connection reset by peer" at requests for http://asdf123.info/.well-known/acme-challenge/30IpwjJqyA7LKANXCvu7gyN9txfYQOqzllBNC3ROPnY

if i remove the _sys_https_redirect iRule, it works fine. 

 

Has anyone an solution for this problem?

 

 

LTM
  • Juergen_Mang's avatar
    Juergen_Mang
    Icon for MVP rankMVP
    Nov 25, 2024

    General: It is not a good idea to add two iRules without explicit priorities and without response guards.

    I assume this is your problem: https://my.f5.com/manage/s/article/K000137608

    I would merge the two iRules.

     

    when HTTP_REQUEST {
    if { [HTTP::path] starts_with "/.well-known/acme-challenge/" } {
        set token [lindex [split [HTTP::path] "/"] end]
        set response [class match -value -- $token equals acme_responses]
        if { "$response" == "" } {
            log local0. "Responding with 404 to ACME challenge $token"
            HTTP::respond 404 content "Challenge-response token not found."
        } else {
            log local0. "Responding to ACME challenge $token with response $response"
            HTTP::respond 200 content "$response" "Content-Type" "text/plain; charset=utf-8"
        }
    } else {
        HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
    }
}

     

    • mwi's avatar
      mwi
      Icon for Cirrus rankCirrus
      Nov 26, 2024

      I cant merge them together, because not every Server needs an redirect, but i made a new redirect rule with  if {[HTTP::has_responded]} and this fixed my problem.

      I would like to understand why this happens, in my head the server get an request, checks if the path starts with "/.well-known/acme-challenge/", if this is true, it tries to respond with the token. Then it tries to redirect, but fails because an response has already sent.

      But why does the server respond with an connection reset by peer?

      • Juergen_Mang's avatar
        Juergen_Mang
        Icon for MVP rankMVP
        Nov 26, 2024

        If an iRule throws an error the connections are reset by LTM. This is a default behavior of LTM. The iRule error is logged in /var/log/ltm and if you enable RST cause logging you should see the RST-Packet send from the F5.

  • Aswin_mk's avatar
    Aswin_mk
    Icon for Cumulonimbus rankCumulonimbus
    Nov 25, 2024

    Hello

    I found this bug in 17.1.1.4, could u please check if it's relating to you

     

    1369673-1 : OCSP unable to staple certificate chain

    Links to More Info: BT1369673

     

    Component: Local Traffic Manager

     

    Symptoms:

    When a server returns a certificate chain that involves an archived Let's Encrypt certificate, the OCSP is unable to staple the full chain.

     

    Conditions:

    An OCSP is configured on the serverside profile, and the client tries to connect to a server that returns certificate chain using an archived Let's Encrypt certificate.

     

    Impact:

    The OCSP is unable to staple the certificate chain. If the stapling is required by the client, the connection will be broken.

     

    Workaround:None

    https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/related/relnote-supplement-bigip-17-1-1-4.html

     

    Br

    Aswin

    • mwi's avatar
      mwi
      Icon for Cirrus rankCirrus
      Nov 26, 2024

      Hi, no that has nothing to do with my Problem.