Tls: no application protocol when attempting to create Let's Encrypt certificate using FortiGate firewall

Hello,

I'm trying to generate a Let's Encrypt certificate using its built-in functionality for that. As recently as the beginning of this month, automatically renewing an existing certificate I obtained the same way was worked fine using a HTTP challenge. Now, however I'm getting the error "tls: no application protocol", and I'm not sure if this message is from the Let's Encrypt service or the ForitiGate. Does anyone here know?

You can find more details about my issue in the FortiGate subreddit here.

https://www.reddit.com/r/fortinet/comments/12r12p2/remote_error_tls_no_application_protocol_when/

Hi @seanthegeek, and welcome to the LE community forum :slight_smile:

Have you upgraded the firmware recently?
If so, are you using multiple interfaces for ACME (WAN)?

2 Likes

[from your reddit link]
"it looks like a TLS challenge method was attempted for the vpn.[redacted].net certificate."

That implies that the nginx config may be misconfigured.
nginx might be redirecting HTTP to HTTPS [instead of the vhost action shown].

3 Likes

Nope. I haven't changed the firmware since the last successful renewal, and I didn't have HTTPS configured on the frontend webserver. it even failed after I set up Let's Encrypt on the frontend NGINX server today just to give that a try. It's super weird.

Review the entire nginx config:
nginx -T

3 Likes

I just did. There is no difference between the successful and unsuccessful configurations.

What's interesting in the ACME logs is that if fails before a challenge is even set up, so I don't think my NGINX configuration is to blame.

Successful process

json
      {
        "when": "Sat, 01 Apr 2023 17:55:03 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for gateway.[redacted].net"
      },
      {
        "when": "Sat, 01 Apr 2023 17:55:03 GMT",
        "type": "progress",
        "detail": "Setting up challenge 'http-01' for domain gateway.[redacted].net"
      },
      {
        "when": "Sat, 01 Apr 2023 17:55:03 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      }

Failure

json
    {
        "when": "Tue, 18 Apr 2023 17:31:30 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains: xx.xx.xx.xx: remote error: tls: no application protocol, problem: urn:ietf:params:acme:error:tls"
      },
      {
        "when": "Tue, 18 Apr 2023 17:31:29 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      }

I'm wondering if there was a change in the ACME API between April 2nd and now that broke the FortiGate implementation.

Check the nginx access logs.
Which vhost is actually handling the HTTP requests to vpn?
Do both names (gateway and vpn) resolve to the same IP?

4 Likes

I just adjusted the NGINX config files to have separate access and error logs for the vpn hostname, and requested the certificate again, and both logs are empty, so the server is never checked.

Yes, both hostnames are hosted on the same server at the same public IP address.

This confirms my assumption:

4 Likes

It failed with the same error message even without a redirect in place in the port 80 vhost config, and the well-known files were never accessed according to the combined access logs before I split them out. I would expect to see at least an initial request in those logs.

I don't think we are on the same page [yet].

I know this will sound tough - but maybe that's just what you need - tough love - lol

You opened this topic - which implies that you require "help".

Are you asking for help?
If not, then I can go about my day.
If so, are you willing to accept the help being provided?
If not, then I can go about my day.
If so, then please follow the requests given.
Like:

I'm pretty certain, that somewhere in that nginx config you will find the reason for this failure.
If you need a second set of eyes to review it, and don't wish to publish that here, feel free to redact it and DM me directly OR ask a colleague to review it.

You can't keep doing the exact same thing and expect the result to change.

3 Likes

Using ICANN Lookup with redacted.net as the input this is what I find.

And DNS Spy report for redacted.net shows

And the webserver seems to be openresty, not nginx.

$ curl -Ii http://redacted.net
HTTP/1.1 200 OK
Server: openresty
Date: Wed, 19 Apr 2023 17:45:32 GMT
Content-Type: text/html
Content-Length: 2830
Last-Modified: Tue, 18 Apr 2023 17:18:11 GMT
ETag: "643ed0d3-b0e"
X-Adblock-Key: MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJRmzcpTevQqkWn6dJuX/N/Hxl7YxbOwy8+73ijqYSQEN+WGxrruAKtZtliWC86+ewQ0msW1W8psOFL/b00zWqsCAwEAAQ_aowVQ3Ju3FNRdf1oFw2WU9GIQ4FYKADK9uVN16yErNKzXnPt1LpkCHbPSXzI/YuqRyjZCtUWsUnlaYmp0Mvq6Q
Cache-Control: no-cache
X-Content-Type-Options: nosniff
Set-Cookie: system=PW;Path=/;Max-Age=86400;
Set-Cookie: caf_ipaddr=98.246.255.230;Path=/;Max-Age=86400;
Set-Cookie: country=US;Path=/;Max-Age=86400;
Set-Cookie: city="Beaverton";Path=/;Max-Age=86400;
Set-Cookie: traffic_target=gd;Path=/;Max-Age=86400;
Accept-Ranges: bytes
Via: 1.1 google
1 Like

Redacted.net is not my actual domain.

1 Like

You have no IP Address for gateway.redacted.net thus the HTTP-01 challenge cannot succeed.

$ nslookup gateway.redacted.net  ns75.domaincontrol.com.
Server:         ns75.domaincontrol.com.
Address:        97.74.107.48#53

** server can't find gateway.redacted.net: NXDOMAIN
$ nslookup www.redacted.net  ns75.domaincontrol.com.
Server:         ns75.domaincontrol.com.
Address:        97.74.107.48#53

www.redacted.net        canonical name = redacted.net.
Name:   redacted.net
Address: 34.102.136.180
$ nslookup redacted.net  ns75.domaincontrol.com.
Server:         ns75.domaincontrol.com.
Address:        97.74.107.48#53

Name:   redacted.net
Address: 34.102.136.180
2 Likes

I see no evidence there have been any issued certificates for redacted.net crt.sh | redacted.net

2 Likes

redacted.net should be example.net

2 Likes

https://www.iana.org/domains/reserved

Then what is your actual domain name?

1 Like

This is why it is so important to provide accurate and complete information when asking for help on a support forum.

3 Likes

Not required to resolve the issue.
[it would be nice to test - and see the HTTP requests redirect to HTTPS]

3 Likes

No disagreement here, but just might make the process easier and and/or quicker was my thought.