Nginx Redirect from www. to @; Weirdness in Certificate

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
lyraswap.com

I ran this command:
letsencrypt --nginx -d lyraswap.com -d www.lyraswap.com

It produced this output:

Some trouble parsing my correct nginx redirect handlers ?

My web server is (include version):

nginx

The operating system my web server runs on is (include version):

Ubuntu 22.02

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

hell no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

1.21.0

Welcome to the community @zdanl

What error leads you to say that?

Something I see is you are missing a DNS entry for your www subdomain. Could this be causing your problem?

nslookup lyraswap.com
A    Address: 51.15.143.248
AAAA Address: 2001:bc8:700:8231::1

nslookup www.lyraswap.com
** can't find www.lyraswap.com: NXDOMAIN
6 Likes

Thanks. Probably just overseen that and assumed the worst.

:+1:

2 Likes

Well, if you really care, it's this. Is happening again:

Problem in /etc/nginx/sites-enabled/default: tried to insert directive "[['if', '($host', '=', 'lyraswap.com)'], [['return', '301', 'https://$host$request_uri']]]" but found conflicting "[['if', '($host', '=', 'lyraswap.com)'], [['return', '301', 'https://lyraswap.com$request_uri']]]".

I was always impressed with Let's Encrypt being able to parse and modify the nginx config for me, so I'm not surprised that with increasing complexity of the Parse Tree it breaks.

I wouldn't know how to fix this without... Generating a full-scale AST.

Anybody?

1 Like

Yes, we do care. That looks like you inserted a redirect from http to https manually and certbot did not insert its own because one existed. It wouldn't want to override something you did intentionally.

They are nearly the same except the existing one named lyraswap.com explicitly but the certbot attempt used the $host variable. The certbot format is slightly better for a fairly obscure reason but both generally work.

What certbot command did you use that caused that message?

6 Likes

Interesting thought that char concatenation in C is slower than taking something that already is in memory. Fair.

letsencrypt --nginx -d fqdn.tld

The speed difference is so small as to not be measurable :slight_smile:

The variable is already being evaluated in the IF statement. Hard-coding the same value twice leaves you more prone to mistakes for future changes.

There is no practical difference the only issue is consistency. If you want certbot to manage your redirects you should let it. If you don't want it to you can disable that option using:

--no-redirect Do not automatically redirect all HTTP traffic to
HTTPS for the newly authenticated vhost. (default:
redirect enabled for install and run, disabled for
enhance)

7 Likes

May I ask something off-topic performance related?

a mov instruction is documented by AMD (and i have seen this wording elsewhere) to copy from a register or a memory location. But they are clearly referring to L-cache address layout, not DRAM. Why are they using this terminology?

Maybe AMD can clarify that for you?

In this forum we talk about a comms product (a TLS cert). Comms based apps are complex things with numerous factors affecting performance. The kind of memory used on a particular server for a particular instruction wouldn't even enter my mind.

There is a time and place for deep dives for performance but this is not it :slight_smile:

6 Likes

The instructions amassing to the cryptography empowering your TLS should worry you much more security-wise than performance, unless Let's Encrypt FPGA is overclockdrifting. So should the firmware on the chips computing the cipher negotiation on the client, as well as the semiconductors authorityizing the fullchain.

Good day.

Most of us on this forum are volunteers who help people get and use Let's Encrypt certs. We are not the ISRG / Let's Encrypt development engineers (although LE staff do monitor this forum and occasionally post).

If you have suggestions to them you might want to post in the Issuance Tech section of this forum.

This thread started with you asking about performance for an IF statement in nginx. What you are now discussing has drifted well beyond that.

For technical details, you might be interested in the Advanced Subscriber topics in this docs page.

7 Likes

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

?

service nginx restart

works.

@MikeMcQ would really appreciate your appreciated volunteering support here.

Config is

server {
   server_name lyraswap.com www.lyraswap.com beta.lyraswap.com;
   root /var/www/lyraswap;
   index index.html;

   location / {
        index index.html;
   }

   listen 80;
}

Is the error the 404 as shown in your prior deleted post? I will assume so but let me know if the error is something else.

I see you got a cert today for your www and beta subdomains in one cert. The server block you show here has those two names plus the apex lyraswap.com. That's fine and should work for getting a cert for all 3 names. I'm just noting this for reference.

What I also see is you have both an A and AAAA record in your DNS for IPv4 and IPv6. But, using your IPv6 address gets a different response than IPv4. The Let's Encrypt authentication of your domain will use IPv6 first and this is what is failing. You should correct your AAAA / IPv6 config or remove the AAAA if you don't have IPv6 working.

curl -I4 lyraswap.com
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Content-Type: text/html
Content-Length: 8211

curl -I6 lyraswap.com
HTTP/1.1 404 Not Found
Server: nginx/1.18.0 (Ubuntu)
3 Likes

Please allow payment for your support by end of month. Thanks.

1 Like

I don't accept payment for my efforts here.

You can donate to Let's Encrypt (here) but it is not required for get assistance. The certs and this forum are free.

6 Likes

Except for Rudy accepting donations for beer I believe :rofl:

4 Likes

And Seth's coffee :coffee: sethschoen is helping people with Let's Encrypt®. :rofl:

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.