Web server failing to get requests.

[Michael Greer]

I have a webserver running that I can hit with a get from my browser, or a third party at another location can hit with postman.  I have access, error and request logs all showing the activity.  When the 3rd party tries from Business Central - an MS cloud ap - I don't even see the access log updated even though tcpdump sees the requests hitting the server in question.  Any insight appreciated.

[Devon Austen]

Hi Michael,

Sounds like it could be either a issue with the web request generated by the MS cloud app or an issue with the web server blocking the request from the cloud app IP address.

I don't know what type of web server you are using and how it is configured so I can't help much with that.

I would suggest checking the web request being sent from the cloud app to make sure it is the same as the one from postman that worked.

[Michael Greer]

Devon,

We are using the Pxplus webserver and using https. I do have a signed cert and have pointed the webserver to a file that has the certificate and the key in it.  2 questions. 1. Would I also put the chain file data in there.  2. If I am logging and the certificate/authentication fails would that activity get logged. With a tcp/ip sniffer we see some activity on the port that we are using (443 of course) but I get nothing in my logs.

Thanks!

[Devon Austen]

For the PxPlus Web Server do you have the access.log enabled? That should log all access to the server if enabled.

[Michael Greer]

Sure do.  Not seeing the attempts at all, so something between the port and the webserver must be shutting us down, yes?

[martinp]

Hey I use the pvx web server you need to do the following:

cat privkey.pem fullchain.pem > pxplus_key.pem

and point your webserver to that SSL pxplus_key.pem everything will work then

Then restart the web server.

PS.  If you are running from an ssh you may find error messages displayed on the main console only, so if you are running Virtually see if u can access console.

[gmundt]

Does the certificate have to be .pem.  There is one with .crt which has both Begin / End Certificate and Begin / End Private Key.  The Postman call works, but the program call doesn't even make it to the logs.

[martinp]

If you are concerned if the web server is even active, you should be able to hit it from the local server?  Is this windows or linux

[gmundt]

It is a linux server running the PxPlus WebServer.  I do know that the server is up.  I also know that a call made from Postman returns a result and the application processes.  A call from Business Central never even makes it to the web server.

1. Is there a difference between pxplus.crt and pxplus.pem?

2. What other locations on the linux server can I see if the call from Business Central is reaching the site?

[martinp]

Where is the server hosted, is this a firewall issue at this point since postman can get in?  postman is coming in on https?  if so your key is fine then

[gmundt]

It's a bit of a confusing issue.  What the network team is indicating is that the request makes it through the firewall, but does not show in the logs for the web service.

[martinp]

But if your logs show fine from postman then it must be able to communicate with external.

Does by chance the linux have some sort of firewall that is blocking, you should be able to trace that.

[gmundt]

I don't believe there are any firewalls on the linux server, but will check that out.

[Mike King]

Did you ever resolve this issue?

If not make sure your PEM file contains your certificate, certificate chain, and private key. 

You can do a quick test of the PEM file with a small PxPlus program that opens a server port using the PEM then trying to connect to it.  For example:

OPEN (1) "[tcp];8888;secure=path-to-pemfile.pem"
WHILE 1
READ RECORD (1,END=*CONTINUE) R$
IF R$="" PRINT "Connection" ELSE PRINT "Recv'd:",R$
WEND

Then you can try to connect to the program using a web browser specifying the port 8888.

You likely will get a error report on the browser complaining the site name doesn't match the certificate but this will at least confirm the PEM file is correct.

[Michael Greer]

This turned out to be related to *something* in MS Business Central.  3rd party had to create a work around.