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.
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.
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?
The speed difference is so small as to not be measurable
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)
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?
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
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.
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.
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)