Forum Discussion
Nimbostratussharepoint running on port 443 - error 404 not found
Hi,
We are implementing sharepoint setup using f5 ltm.
servers: spws1.company.com spws2.company.com
are running using https or 443
when i configured it with f5 running on port 443, the response is "404 not found",
we have clientssl and serverssl profile for the virtual server.
I also tried using iApps, but still error occurs.
BTW, the sharepoint version is 2013. Did i miss something out with my configuration?
I tried curl command from f5 to each virtual servers, and it is working.
15 Replies
Hi Allanwyn, it's hard to say without seeing your configuration. Are your SharePoint pool members being marked up by the HTTPS monitor? What send and receive strings are you using? If they are being marked up, you should at least be able to access the site using the same URL as the monitor send string.
Allanwynn_16283Hi, yes it is up by a HTTPS monitor, actually I used the iApps hoping it would work with that. I am not familiar with this "you should at least be able to access the site using the same URL as the monitor send string.", I leave the health monitor default that was used by the iApps. I notice the sharepoint server site is accessible via only its hostname. I also inputted the servers using fqdn on the pool configuration.
RyannnnnnnnnAltocumulus
so from your BIG-IP have you curl'd like so (obviously substituting names and IP's)
curl -v -H "Host: sharepoint.company.com" https://1.1.1.10What was the output?
- Allanwynn_16283Hi Sorry for the very late reply [root@mkti-f5-lb1:Active:In Sync] config curl -v -H "Host: spws1.pgpc.net" https://172.16.2.190 * About to connect() to 172.16.2.190 port 443 (0) * Trying 172.16.2.190... connected * Connected to 172.16.2.190 (172.16.2.190) port 443 (0) * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS alert, Server hello (2): * SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed * Closing connection 0 curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
- Allanwynn_16283BTW, the first output is form F5 to the Server, This from F5 to the virtual server itself [root@mkti-f5-lb1:Active:In Sync] config curl -v -H "Host: sp.pgpc.net" https://172.16.2.127 * About to connect() to 172.16.2.127 port 443 (0) * Trying 172.16.2.127... connected * Connected to 172.16.2.127 (172.16.2.127) port 443 (0) * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS alert, Server hello (2): * SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed * Closing connection 0 curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
Ryan_80361Cirrostratus
so from your BIG-IP have you curl'd like so (obviously substituting names and IP's)
curl -v -H "Host: sharepoint.company.com" https://1.1.1.10What was the output?
- Allanwynn_16283Hi Sorry for the very late reply [root@mkti-f5-lb1:Active:In Sync] config curl -v -H "Host: spws1.pgpc.net" https://172.16.2.190 * About to connect() to 172.16.2.190 port 443 (0) * Trying 172.16.2.190... connected * Connected to 172.16.2.190 (172.16.2.190) port 443 (0) * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS alert, Server hello (2): * SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed * Closing connection 0 curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
- Allanwynn_16283BTW, the first output is form F5 to the Server, This from F5 to the virtual server itself [root@mkti-f5-lb1:Active:In Sync] config curl -v -H "Host: sp.pgpc.net" https://172.16.2.127 * About to connect() to 172.16.2.127 port 443 (0) * Trying 172.16.2.127... connected * Connected to 172.16.2.127 (172.16.2.127) port 443 (0) * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS alert, Server hello (2): * SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed * Closing connection 0 curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
- Kevin_Stewart
Employee
A few things:
-
You do need to specify the -k option in your cURL commands if you're not applying a CA cert. The -k option allows cURL to ignore SSL validation errors.
-
A 404 error is an HTTP thing, very likely coming directly from the server. This implies that client and server side SSL are working and that the application itself is sending a "not found" error in response to whatever you're asking for.
-
- Kevin_Stewart
We know a few things. We know that a 404 is an HTTP error. We know that the BIG-IP does not send HTTP errors. And we know by virtue of the first thing that SSL isn't the issue. So there's a 99.999% chance that this is an application-level problem, and that the client is asking for something that server says doesn't exist. Applications can sometimes do some unusual things behind a proxy server. The best way to start troubleshooting this is with a client side browser-based capture like HTTPWatch or Fiddler. You could probably even get away with FireFox's Live HTTP Headers plugin. What you're looking for is the set of requests and responses leaving and returning to the browser, and which request triggers the 404.
Anthony_EpronHello,
Have you try a tcpdump for see if your BigIP send request to your back end server and if you have respond to this server ?
In SSH use this command : tcpdump -ni /"partition_name"/"vlan_name" host "your_destIP"
- Allanwynn_16283
how about error 400 bad request, are your familiar on how to solve this issue with f5?
- Anthony_EpronTry the tcpdump. If you request go to your serveur SharePoint it's not a problem with the load balancing of your BigIp. The Sharepoint work in local host ?
THiBad request may indicate that something is wrong in the headers of the HTTP request. For example I've seen this coming from IIS server when the Host header is missing. HTTP/1.1 requires it. What did you get on your curl with -k flag (to ignore cert errors), between F5 and the server?
- Kevin_Stewart
how about error 400 bad request, are your familiar on how to solve this issue with f5?
The error is most likely coming from the application server itself, which may be an artifact of being behind a proxy. The best way to troubleshoot is to understand what the client (browser) is asking for, and when the server responds with a 404.
