Forum Discussion
Shadow
Cirrus
CirrusTrouble applying GoDaddy certificate to a virtual server
I have created a few virtual servers and applied certs. They work just fine because they are using our internal CA. I have one now that uses a GoDaddy cert. I was provided a GoDaddy pfx file.
I imported the cert and key without issues.
I created the SSL profiles.
In the CLientSSL profile, I chose the newly imported GoDaddy cert for Certificate, Key and Chain.
I added the profile to the virtual server.
When I open the virtual server in any browser, I get "The site can't be reached". Using FireFox, I get the error, "Error code: PR_CONNECT_RESET_ERROR". Because it's not an invalid cert error, I can't easily troubleshoot.
Am I doing something that is glaringly wrong?
Shadow it looks like F5_Design_Engineer is on the same track as me. The F5 is receiving a RST from the backend between it and the server so asymmetric routing or the destination pool member itself.
Hi Shadow ,
Now , You Must take a packet capture in both sides ( Client and Server ) sides , I feel that the Backend servers that Reset this traffic not Bigip itself the ssl negotiations went correct from the Client side.
Bigip took The client Application Data and forwarded it to Backend server , so most properly the backend server itself restted this traffic for various reasons need to be checked furtherly.Hi Shadow ,
Forget about my last reply , as I saw you captured the Full stream of ( Client and server side ).
It's very clear that Rest comes from IPs ( 173.235.20.160 & 161 ) which your Backend servers.
I see that your Servers couldn't able to establish 3-way handshake with Bigip , Servers reject the First SYN Packet from Bigip , but the most confusing me how the https health monitor marks your pool as up and at the same time bigip can't establish with servers 3-way handshake on real data traffic.
>>> I found something strange to me :
Do you see MSS value ? it's 1212 which not the standard , it's very very important to check your backend servers's MTU and the MTU in Bigip server side must be compatable with your backend servers that's why your servers Reset this connections , make sure that MTU matches each side ( Bigip server side and Backend servers )
I will tell you another idea >>> What about take a packet capture for your heath monitor to see while monitoring Bigip sends monitor packet with this MSS = 1212 or not as from your pool configuration I see the Https monitor marks your Backend servers Up and Can establish 3-way handshake correct.
So we need to compare between Client traffic on server side and Health monitor traffic on server side as well.
Concentrate more in the server side not ssl certificates.
I will be waiting your results 🙂I have a ticket open with support and they have confirmed it is not a GoDaddy issue, but rather the backend server. Resets are coming after the redirection.
- Shadow
I have a ticket open with support and they have confirmed it is not a GoDaddy issue, but rather the backend server. Resets are coming after the redirection.
Shadow ,
I have checked your pcap and it seems there is a Checkpoint firewall in between your F5 Internal interface and Backend pool memeber , and Checkpoint is sending RST packets.
Can you try change server ssl profile to serverssl-secure?
Your environment seems F5 is intalled on a VMWARE and there is a checkpoint firewall between F5 and backend real server.
Here are the screenshots from your tcpdump in wireshark
Can you check if there is a Checkpoint firewall in between:
I have checked the SSL certificate details here:
SSL Server Test: ssl.afbic.com (Powered by Qualys SSL Labs)
Attached is the pdf below for full report .
Check for SSL packets drop on Checkpoint.
One more point I noticed in your CURL output:
Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application layer protocols. It is needed by secure HTTP/2 connections, which improves the compression of web pages and reduces their latency compared to HTTP/1.x.
Since APLN is an extension of TLS, it implies that TLS is being used. Even if the server is not using ALPN, but some other earlier protocol, both protocols must be extensions of TLS or they would not be able communicate.
In the above verbose output, "ALPN," is a prefix indicating that the rest of the line is the status of ALPN negotiation by the client side.
- Shadow
I chaned the profile to serverssl-secure and got the same results.
The networking team is telling me there is no checkpoint firewall.
- Paulius
MVP
Shadow as Mohamed_Ahmed_Kansoh stated, it would be helpful if you could provide a tcpdump of the user connecting to see exactly what happens because the error you're receiving seems to be an application related issue.
- Shadow
I uploaded a zip with this information in my response to F5_Design_Engineer.
- Paulius
Shadow Can you provide the configuration of the AFBSSL pool so I can correlate the information in your tcpdump please? I have looked at the tcpdump so far and it looks like the F5 is issuing a RST because the remote system it's attempting to reach most likely issued a RST to it causing this connection to not function properly.
Hi Shadow ,
Could you please share the output of your VIP and the SSL profile using tmsh commands as follows:
in tmsh mode:
list ltm virtual NAME_OF-YOUR_VIP all-properties
list ltm profile client-ssl NAME_OF-YOUR_PROFILE all-properties
I am suspecting if you are using SNAT or Automap for address translation or port translation or not, cauing any sort of assymentric routing.
As I dont have your VIP configuration i cannot check if you have translate-address disabled and translate-port disabled ?
Please read this
K79443053: Address translation and port translation behavior on a standard virtual server
https://support.f5.com/csp/article/K79443053
as if you are talking about asymetric routing
https://support.f5.com/csp/article/K13558
K13558: Allowing asymmetrically routed connections across multiple VLANs (11.x - 16.x)
then you will need to fix your TCP profiles.
If you are using any iRules we can tshoot ,only when you will provide your VIP and SSL profile configurations.
HTH
Best Regards,
F5 Design Engineer
- Shadow
Here's the info you requested.
Hi ,
This infomation looks but do not provide any details to the error you care facing.
Can you run this tcpdump and share the pcap:
You need to take a tcpdump on the BigIP to see where the reset is being generated from, and why.
For onscreens display only
tcpdump -n -v -s0 -i0.0:nnnp host <vip IP> and port 443
Also, try running a curl command to the VIP
curl -kv https://<vip fqdn>/ --resolve <vip fqdn>:443:<vip IP>
Try this tcpdump and share the output to be caputed in a PCAP file :
tcpdump -vvv -s0 -nni 0.0:nnnp host <vip IP> and port 443 -w /var/tmp/`/bin/hostname`_`date +%Y-%m-%d--%H%m%S`-DADDY-SSL-ISSUE.pcap
Best Regards,
F5 Design Engineer
Hi Shadow ,
Make sure that you attached the correct intermediate certificate in Chain section.
Take a packet capture for a sample client ip and share it here or private if this available with you- Shadow
I provided it in my response to F5_Design_Engineer.
Hi Shadow ,
Forget about my last reply , as I saw you captured the Full stream of ( Client and server side ).
It's very clear that Rest comes from IPs ( 173.235.20.160 & 161 ) which your Backend servers.
I see that your Servers couldn't able to establish 3-way handshake with Bigip , Servers reject the First SYN Packet from Bigip , but the most confusing me how the https health monitor marks your pool as up and at the same time bigip can't establish with servers 3-way handshake on real data traffic.
>>> I found something strange to me :
Do you see MSS value ? it's 1212 which not the standard , it's very very important to check your backend servers's MTU and the MTU in Bigip server side must be compatable with your backend servers that's why your servers Reset this connections , make sure that MTU matches each side ( Bigip server side and Backend servers )
I will tell you another idea >>> What about take a packet capture for your heath monitor to see while monitoring Bigip sends monitor packet with this MSS = 1212 or not as from your pool configuration I see the Https monitor marks your Backend servers Up and Can establish 3-way handshake correct.
So we need to compare between Client traffic on server side and Health monitor traffic on server side as well.
Concentrate more in the server side not ssl certificates.
I will be waiting your results 🙂
