121–130 of 167 posts
Earlier quoted context omitted.
TLSA DNS records coupled with DNSSEC could eliminate the need for CAs but we still have a long way to go until we can rely on it.
Then you just move all the WoT issues of the CA system into DNS, no?
It seems that Let's Encrypt is back up. I think, in the past, mods have put an extra down-weight on "X is down" stories, once 'X' is back up. Since this discussion now has interesting stuff related to Let's Encrypt—and products which use Let's Encrypt—I hope the mods are willing to forgo the down weight, and instead just change the post title to something like "Let's Encrypt Was Down".
I'm still getting 504s and timeouts from https://acme-v01.api.letsencrypt.org/acme/new-reg and https://acme-v01.api.letsencrypt.org/directory (trying from Lisbon, PT) Edit: Akamai is issuing the 504 when hitting https://acme-v01.api.letsencrypt.org/acme/new-reg so I guess the origin servers are still overloaded...?
Earlier quoted context omitted.
Caddy restarts gracefully with zero downtime. If you're killing the process and starting one anew, you're doing it wrong. Use signal USR1 to gracefully apply new configuration changes. Failed reloads fall back to the current working configuration without any changes or downtime. https://caddyserver.com/docs/cli#usr1
What if there's a reason to restart the server or spawn a new one?
I think LE is a huge boon to the internet. But I would really love for someone like Amazon, Google, Facebook, or Microsoft to set up a separate provider that implements the same thing. Redundancy is super important here and clearly just one organization can't guarantee 100% uptime.
I'd vote for Gandi.net or Github to do it. FB definitely not, MS rather not, Google not if I could avoid it. Amazon maybe.
Besides, this doesn't have to be a thing that's under the direct control of any of these organizations, but rather a separate entity that's just financed by them.
Gandi or GitHub would be cool too.
Earlier quoted context omitted.
Thanks for pointing this out! Going through the documentation, another thing that surprised me was the SSLStaplingStandardCacheTimeout setting. If I understand this correctly, by default Apache will only cache OCSP responses for 1 hour, even if they are still valid for days. I guess increasing this to 1 day or something would make sense as well.
> If I understand this correctly, by default Apache will only cache OCSP responses for 1 hour, even if they are still valid for days. I guess increasing this to 1 day or something would make sense as well. Yeah, that's another major problem. But increasing that doesn't really fix anything in a reasonable way. There shouldn't be any cache timeout, this option doesn't make any sense. It should cache as long as the repl…
Apache checks if cached reply is still valid and if it's not it attempts to renew it.
At least in 2.4.10 shipped in Debian Jessie. Relevant code is in modules/ssl/ssl_util_stapling.c, stapling_cb()
Earlier quoted context omitted.
I'm still getting 504s and timeouts from https://acme-v01.api.letsencrypt.org/acme/new-reg and https://acme-v01.api.letsencrypt.org/directory (trying from Lisbon, PT) Edit: Akamai is issuing the 504 when hitting https://acme-v01.api.letsencrypt.org/acme/new-reg so I guess the origin servers are still overloaded...?
I'm experiencing the same from Kuala Lumpur.
This is also why you don't wait until the last day before renewing. (But no-one does that, right?)
certbot certonly --webroot --webroot-path /var/www/{{ domain }} --agree-tos -m {{ email }} --domain {{ domain }} --renew-hook "service nginx reload"
If certbot was installed with PIP, a CRON job will be automatically created and it will run with whatever arguments the certificate was first obtained with (--renew-hook is obviously important).
Earlier quoted context omitted.
Then wait until you see how caddy handles fully qualified domain names! Caddy will just refuse to even handle them. Every single other server on this planet handles them properly, but caddy doesn’t – and mholt considers that working as intended. Try out: https://www.google.co.uk./ https://www.microsoft.com./en-us/ https://www.amazon.com./ serve the page directly; https://www.facebook.com./ redirects to the relative d…
Is there a bug for this? That's out of spec
Earlier quoted context omitted.
> I'm not sure I understand how slash collapsing is affecting this. Slash is a reserved character and presumably if it the data was correctly encoded should never have ended up in the URI in the first place? base64 uses 64 characters: A-Za-z0-9 (62) and two symbols, commonly '/' and '+'. (As well as a third symbol, '=', used at the end to handle padding.) That would work in a URI, most of the time, except if you happ…
The spec says the base 64 should be URL encoded, so why aren't the slashes turned into "%2F"?
But some applications will decode the percent-encoding too early in the process of normalizing, security-escaping, and processing the URL. Encoded slashes in URLs are problematic [1][2][3][4][5].
[1] https://httpd.apache.org/docs/2.4/mod/core.html#allowencoded... [2] http://stackoverflow.com/questions/3235219/urlencoded-forwar... [3] http://codeinthehole.com/tips/django-nginx-wsgi-and-encoded-... [4] http://stackoverflow.com/questions/3040659/how-can-i-receive... [5] https://groups.google.com/forum/?fromgroups#!topic/django-us...