Forum Discussion
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?
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] } }
- mwiCirrus
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?
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_mkCumulonimbus
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
- mwiCirrus
Hi, no that has nothing to do with my Problem.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com