This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FileMaker does not accept reverse proxy SSL certificate

Hi people,

I hope this is the correct forum. It took me some time before I found out how to even post a question.

I have this FileMaker database server which is sitting in the private network. Using NAT, I have configured all traffic over port 5003 to go to the internal IP of that server.

Because it is using SSL encryption, I have set up a reverse proxy entry for https, and linked my domain it's wild card certificate to it, and I am passing host headers.

That worked fine until some months ago, don't know exactly, probably after some upgrade or update.

Now, when I connect from the outside to the server, it is telling me that the certificate is invalid. There is a button to look at the certificate from that dialog, and it shows that all parts of the certificate ( cert, intermediate, CA ) are all OK.

This does not happen when I connect from the inside, using the same DNS name.

I realise this is not exactly main stream http / https proxying, but just maybe someone has experience here with this particular setup.



This thread was automatically locked due to age.
Parents
  • Hi,

    I'm currently trialling FileMaker and hit this problem (for some reason I'm now struggling with the 5003 NAT even that 443 with WAF is fine).

    Anyway, as has already been mentioned in other posts, the reverse proxy adds in extra headers (x-forwarded-****).

    This appears to mess with the URL Rewrite rules in IIS that FileMaker uses to point public addresses to local services.

    The fix for me was for add in my own rewrite rule in the site web.config file (at C:\Program Files\FileMaker\FileMaker Server\HTTPServer\conf in my installation).

    I put it as the first rule, to remove the offending headers before FileMaker deals with the request.

    <rule name="X-forward" patternSyntax="Wildcard">
        <match url="*" />
        <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
        <serverVariables>
            <set name="HTTP_X_FORWARDED_FOR" value="" />
            <set name="HTTP_X_FORWARDED_SERVER" value="" />
            <set name="HTTP_X_FORWARDED_HOST" value="" />
        </serverVariables>
        <action type="None" />
    </rule>

    I had to add in HTTP_X_FORWARDED_FOR and HTTP_X_FORWARDED_SERVER as additional Server Variables in IIS Manager (HTTP_X_FORWARDED_HOST was already allowed by default).

Reply
  • Hi,

    I'm currently trialling FileMaker and hit this problem (for some reason I'm now struggling with the 5003 NAT even that 443 with WAF is fine).

    Anyway, as has already been mentioned in other posts, the reverse proxy adds in extra headers (x-forwarded-****).

    This appears to mess with the URL Rewrite rules in IIS that FileMaker uses to point public addresses to local services.

    The fix for me was for add in my own rewrite rule in the site web.config file (at C:\Program Files\FileMaker\FileMaker Server\HTTPServer\conf in my installation).

    I put it as the first rule, to remove the offending headers before FileMaker deals with the request.

    <rule name="X-forward" patternSyntax="Wildcard">
        <match url="*" />
        <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
        <serverVariables>
            <set name="HTTP_X_FORWARDED_FOR" value="" />
            <set name="HTTP_X_FORWARDED_SERVER" value="" />
            <set name="HTTP_X_FORWARDED_HOST" value="" />
        </serverVariables>
        <action type="None" />
    </rule>

    I had to add in HTTP_X_FORWARDED_FOR and HTTP_X_FORWARDED_SERVER as additional Server Variables in IIS Manager (HTTP_X_FORWARDED_HOST was already allowed by default).

Children
  • Hi Giles,

    Thanks very much for sharing this.

    I followed your instructions and added the rule add the bottom of the rules section in the config XML file.

    I also added the 2 server variables in IIS, at the level of the FMS site ( where they are local ). IIS then wrote some extra lines in the config file:

    <allowedServerVariables>
    <add name="HTTP_X_FORWARDED_SERVER" />
    <add name="HTTP_X_FORWARDED_FOR" />
    </allowedServerVariables>

    I rebooted the OS just to make sure and tried it out from an internet machine, but it didn't solve the problem.

    But I think I know now what the problem is. See the next post.