Re: mod_proxy_hcheck with Istio
Stanislav Samek <[email protected]>
| Newsgroups | gmane.comp.apache.user |
|---|---|
| Message-ID | <CAP1rkOJQCoY_pkO9kn-BSh6bhP2MJ3-cGQ36ux3+-fhdyqWjwg@mail.gmail.com> |
Hi, I don't think that there is an issue with ssl. We have SSLProxyEngine turned on and also a backend name match with CN. In attachment you can find output from the curl command. Thank you so 28. 9. 2024 o 22:02 Daniel Ferradal Márquez <[email protected]> napísal(a): > > On 24/9/24 8:25, Stanislav Samek wrote: > > ... > > Probably it will be a problem that Istio is exposing endpoints in > > HTTP/2 revision. Don't you have a problem with this? > > > > Here is part of our configuration: > > > > ProxyPassMatch ^/foobar/v1/(.*)$ balancer://application/api/$1 > > ProxyPassReverse ^/foobar/v1/(.*)$ balancer://application/api/$1 > > > > ProxyHCExpr checker {%{REQUEST_STATUS} =~ /^[234]/} > > > > <Proxy balancer://application> > > BalancerMember https://foobar-a.stage.cloud addressttl=3600 > > hcexpr=checker > > BalancerMember https://foobar-b.stage.cloud addressttl=3600 > > hcexpr=checker > > > > # Optional: Load balancing method > > ProxySet lbmethod=byrequests > > > > </Proxy> > > > > Thank you > > > SSLProxyEngine should be set to on. Make sure you have it. > > Also certificate provided by backend should match name in its CN or > AltName to the FQDN you are pointing in your BalancerMember directives, > otherwise you must set SSLProxyCheckPeerName off of fix certificates in > backend. > > You could also try "curl --http1.1 -v https://foobar-a.stage.cloud" to > check what you get exactly. > > -- > -Daniel > Find help at #httpd in Libera.chat > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
output.txt
(text/plain, 1.9 KB)
curl --http1.1 -v https://foobar-a.stage.cloud * Trying 10.x.y.z... * TCP_NODELAY set * Connected to foobar-a.stage.cloud (10.x.y.z) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=CZ; O=XCV; OU=AP; CN=*.stage.deposit-eligibility.kbcloud * start date: Dec 7 14:30:49 2023 GMT * expire date: Dec 6 14:30:49 2025 GMT * subjectAltName: host "foobar-a.stage.cloud" matched cert's "*.stage.cloud" * issuer: C=CZ; O=XCV; CN=Interni CA Osobni * SSL certificate verify ok. > GET / HTTP/1.1 > Host: foobar-a.stage.cloud > User-Agent: curl/7.68.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Mark bundle as not supporting multiuse < HTTP/1.1 302 Found < content-security-policy: frame-ancestors 'none' < location: https://foobar-a.stage.cloud/api/swagger-ui < content-language: en-US < content-length: 0 < date: Mon, 30 Sep 2024 08:29:07 GMT < strict-transport-security: max-age=31536000; includeSubDomains; preload < x-frame-options: SAMEORIGIN < x-content-type-options: Nosniff < referrer-policy: strict-origin-when-cross-origin < * Connection #0 to host foobar-a.stage.cloud left intact