SSL issues with new setup

irbk Would you mind sharing the virtual server configuration and any associated configuration such as SSL profile, SSL cert information, and pool member configuration. Based on your explanation the F5 shouldn't have any reason it would work for 1 domain and not the other if the SSL cert is a wildcard for *.domain.com because that includes all FQDNs mentioned. I would recommend running the following tcpdump to see if it provides any additional information.

tcpdump -nni 0.0:nnp host <virtual_server_IP> -w /shared/tmp/ssl_tshoot.pcap

Once you have run your test you can cancel the tcpdump and it should be saved in /shared/tmp/ as ssl_tshoot.pcap. You can copy the pcap off the F5 and open it up in wireshark to see if you can find anything to explain the SSL handshake issue.

Can you post the VS configuration?

What's the easiest way to share the VS config?

ltm virtual BigIP_443 {
creation-time 2023-09-26:15:10:23
destination <VS IP>:https
ip-protocol tcp
last-modified-time 2023-09-28:09:52:29
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_443
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Modified_Wildcard {
context clientside
}
Modified_serverssl {
context serverside
}
analytics { }
tcp-analytics { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool BigIP-Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 3
}

The above was just a configuration I was playing around trying to get something like just SSL Passthrough to work.  I think the end goal is the SSL Bridging because you get better traffic analysis and load balancing or something like that.  
This is what the profile was before I started just trying stuff this am.

ltm virtual BigIP-Nav_443 {
creation-time 2023-09-26:15:10:23
destination <VS IP>:https
ip-protocol tcp
last-modified-time 2023-09-28:11:01:52
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_443
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Wildcard23-24 {
context clientside
}
analytics { }
tcp-analytics { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool BigIP-Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 3
}

Here is the SSL profile

ltm profile client-ssl Wildcard23-24 {
app-service none
cert-key-chain {
WildCard23-24_0 {
cert WildCard23-24
key WildCard23-24
passphrase <encrypted>
}
}
defaults-from clientssl
inherit-ca-certkeychain true
inherit-certkeychain false
log-ssl-c3d-events debug
log-ssl-client-authentication-events debug
log-ssl-forward-proxy-events debug
log-ssl-handshake-events debug
}

And here is the pool

ltm pool Nav_Pool_443 {
load-balancing-mode predictive-member
members {
Nav01:https {
address <IP>
session monitor-enabled
state up
}
Nav02:https {
address <IP>
session monitor-enabled
state up
}
}
monitor https
}

Thanks again!

I didn't know if you might want the profiles as well listed in the VS, so here you go

ltm profile http LC-http {
app-service none
defaults-from http
insert-xforwarded-for enabled
proxy-type reverse
}

ltm profile one-connect LC-oneconnect {
app-service none
defaults-from oneconnect
source-mask 255.255.255.255
}

ltm profile tcp LC-tcp-lan {
app-service none
defaults-from f5-tcp-lan
idle-timeout 28800
}

Yes, that's a really high idle timeout but it was put there becuase people will run reports that run for like 8 hours and we didn't want to system timing them out while a report was running.  I'm not sure if it's necessary but before we can test that we need to get the SSL part working first.

posting the TCPdump is a little bit more tricky.  I think this may be the best way