HELP how do I see what protocol I'm using?

Help
1

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: clientmail.pdxclouds.net

Hi All,

So I had a cert coming up for renewal so I decided to check during the "maintenance outage" to see if my certbot client was using the "blessed" protocol. Which I did this morning, running a certbot renewal at around 10:00am. I got an error message about the servers being offline and to check https://letsencrypt.status.io/ for status.

So OK, I figured, my certbot is using the heretical protocol and needs to be changed. But just for grins, I ran the renewal request 5 minutes later - no change in options - and the certs renewed. Yet the https://letsencrypt.status.io/ is still showing down - even as I type this.

So what the fark is going on, please?

Did I renew using the heretical protocol and someone is just being lazy at updating https://letsencrypt.status.io/

Or did I renew using the blessed protocol and I'm good?

This business of "we are gonna deliberately break it to convince people to switch over" isn't going to work if the https://letsencrypt.status.io/ doesn't EXACTLY track the REAL status of whether the cert servers are deliberately in a busted status or not.

It would seem a far more OBVIOUS way of doing this would be to issue a message saying "your cert is renewed using the heretical protocol and the priests have determined you aren't blessed so repent before the end!" instead of just deliberately breaking things.

My $0.02 on this. And no I still don't know if the LetsEncrypt priests have decided if I'm among the saved or not.

1 Like
2

There are a lot of things going on at once, yes, and the status page seems to be confusing many people lately so you're not alone. In addition to ACME v1 going away, they are doing some maintenance on the staging environment (which is what's used when you pass --dry-run to certbot, and I'm guessing is something you saw while testing).

Can you give your certbot version by running certbot --version ? If it's something even kind-of-recent it's probably fine.

2 Likes
3

Hi @tedm

it's always bad to run a client at 10:00, 11:00 etc.

Add some random minutes / seconds.

4

Sounds like a manual execution of certbot, not automated, to me. Not really necessary to add random minutes to a manually executed command.

1 Like
5

certbot version 1.0.0

2 runs both for renewals. One renewal via the embedded webserver 1 run using dns for the other server. SEEMS like the newer protocol but still got the maintenance error.....

I dug around and here's the log:

2021-04-26 09:59:49,841:DEBUG:certbot._internal.main:certbot version: 1.0.0
2021-04-26 09:59:49,842:DEBUG:certbot._internal.main:Arguments: ['--standalone', '-d', 'mail.pdxclouds.net']
2021-04-26 09:59:49,842:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,Pl
uginEntryPoint#standalone,PluginEntryPoint#webroot)
2021-04-26 09:59:49,897:DEBUG:certbot._internal.log:Root logging level set at 20
2021-04-26 09:59:49,898:INFO:certbot._internal.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2021-04-26 09:59:49,913:DEBUG:certbot._internal.plugins.selection:Requested authenticator standalone and installer None
2021-04-26 09:59:49,924:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot._internal.plugins.standalone:Authenticator
Initialized: <certbot._internal.plugins.standalone.Authenticator object at 0x803543d50>
Prep: True
2021-04-26 09:59:49,925:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot._internal.plugins.standalone.Authentica
tor object at 0x803543d50> and installer None
2021-04-26 09:59:49,925:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator standalone, Installer None
2021-04-26 09:59:49,945:DEBUG:certbot._internal.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=()
, agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri='https://acme
-v02.api.letsencrypt.org/acme/acct/101158083', new_authzr_uri=None, terms_of_service=None), 65c936800c90ed1593ed8b21f123e592, Meta(creati
on_dt=datetime.datetime(2020, 11, 3, 3, 44, 45, tzinfo=), creation_host='smtp.portlandia-servers.com'))>
2021-04-26 09:59:49,947:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2021-04-26 09:59:49,953:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org:443
2021-04-26 09:59:50,573:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 503 178
2021-04-26 09:59:50,574:DEBUG:acme.client:Received response:
HTTP 503
Server: nginx
Date: Mon, 26 Apr 2021 16:59:44 GMT
Content-Type: application/problem+json
Content-Length: 178
Connection: keep-alive
ETag: "5a590733-b2"

{
"type": "urn:acme:error:serverInternal",
"detail": "The service is down for maintenance or had an internal error. Check https://letsencrypt.status.io/ for more details."
}

2021-04-26 09:59:50,575:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/usr/local/bin/certbot", line 11, in
load_entry_point('certbot==1.0.0', 'console_scripts', 'certbot')()
File "/usr/local/lib/python3.7/site-packages/certbot/main.py", line 14, in main
return internal_main.main(cli_args)
File "/usr/local/lib/python3.7/site-packages/certbot/_internal/main.py", line 1350, in main

1 Like
6

If you have

that error with a http status between 500 and 599, it's not your problem.

Then it's a Letsencrypt problem -> try it again later.

2 Likes
7

It's pointed to acme-v02.api.letsencrypt.org, so you're using the current protocol and are all set in that regard.

There was production maintenance from 16:35 to 17:06 UTC, so if your server is keeping its timestamp logs in UTC-7 (I think that's US's Pacific Time Zone at the moment) I believe that's what you ran into.

3 Likes
8

Then I caught someone with their pants down.

To repeat what I said in the first posting: If the error is going to refer people to a website like https://letsencrypt.status.io/ then that must EXACTLY track maintenance outages. You need to give your actual techs running the maintenance on the servers access to that site to make updates. Before they kick off whatever it is they update it and when whatever it is finishes they update it again. If you try inserting "flappers" in between the techs and that website then the delays are going to make that site worthless. And if the techs DO have access - remind them that these are production servers and any outage even of a few minutes will be noticed and they need to be diligent about communicating to the public with that site.

Otherwise as I said it would be MUCH better for the error message returned to be more explicit.

"The service is down for maintenance or had an internal error. Check https://letsencrypt.status.io/ for more details."

just does not cut it. Are we trying to save bits in the computer for the environmentalists or something? Here's a much better one:

"The service was taken down at 16:35 on 4/26/21 for maintenance and is expected to be back up sometime in the next hour or two or whenever we feel like it. Share and Enjoy! - Sirius Cybernetics Corporation."

:slight_smile:

Rule of thumb on this - if the error message refers to a KNOWN outage that is always better. Otherwise it's like calling the fire department and saying "the forest is burning down I can see the black smoke coming from right behind your fire station" and them saying "what forest?"

1 Like
9

I've not read your entire post, but please do note that the majority of peope posting here are just volunteers of this Community, just like you, and not Let's Encrypt employees. Just users of Let's Encrypt, like you, helping other Let's Encrypt users.

You can recognise LE staff by their title. It'll include something like "Let's Encrypt staff".

3 Likes
10

Yes. We try to do exactly this.

3 Likes
11

Thanks, James! I do appreciate what you guys are doing. The encryption game has become a giant racket. The idea that you need a https cert for a website that is nothing more than a public yellow pages entry for a company - as at least half the sites on the internet are - is idiotic.

For every web site out there that requires passwords or some such where SSL is justified there's a thousand others where it is not and most of those are owned by people who are completely bewildered by all of this and don't understand it. Then the CA's come in like vultures selling them $50 a year certs that do absolutely nothing for them. Of course they can go unencrypted but then Google de-ranks their sites.

You guys strike a blow for the little guys and what you are doing is good and you should be proud of it.

2 Likes
12

Until someone starts substituting out the resources your website delivers unsecurely (e.g. images, videos, fonts, scripts, the whole page) for whatever they want... Man-in-the-middle anyone?

:thinking:

Where you wrote "child safety" in your business description, I really think that "carcinogen production" is what you meant, so... your entire website becomes my own, personal mad lib.

See @rmbolger's post right below for more information.

2 Likes
13

TLS is just as much about data integrity as it is about data privacy. When you visit an HTTP-only site, neither you nor the site operator can be sure that the data requested by the browser hasn't been tampered with by a 3rd party. There was a (thankfully short) period of time before certs really started becoming widespread (particularly in places with "free" wifi) where internet providers would intercept HTTP web traffic and inject ads into the sites being requested. The same thing can happen with malicious attackers...changing innocent links to malicious ones...altering content to provide false data, etc. TLS protects against all of that even when there's no sensitive/secret data to protect with the encryption.

Bah, @griffin beat me to the punch.

3 Likes
14

I strike with the quickness.

:grin:

1 Like
15

Not so. Encrypting your website connections is one of the best things you can do.
Securing your server is also one of the best things you can do.
If you don't understand the implications of securing your public domain than your "head is in the sand".
Every aspect of "Best Practices" and layered security is in play here.
Do what you want, but watch your logs very closely .
Let's Encrypt offers FREE TLS/SSL certs for those who understand they need it (in addition to all the other layers of security you can implement on your server)
You must also harden your server from undesirable entities to protect your data.
NOT DOING COMMERCE? so what. Every opportunity we give the script kiddies is an opportunity to fail.
Run your instance like it has a billion dollars behind it and you will be most of the way there.

My Thoughts
Rip

2 Likes
16

A MiM attack on a Yellow Pages site that is not transactional can be done by attacking the DNS servers, a gigantic number of CPE devices out there use DNS caches that are old code and full of vulnerabilities. All you have to do is attack the DNS server on the CPE and substitute your own IP address for the address of the target then setup a web page that is non-https. In fact many ISPs run DNS servers that have vulnerabilities you don't even have to bother with the CPEs.

The trend these days in advertising websites is to post the URL's WITHOUT the https or http prefix - often without the www. If I type in "somesitenameisawonthebackofatruck.com" into my web browser it's going to start with a http: query not an https: query. Check your referral logs for incoming queries and see just how many of them started out http:/somedomain.com that you had to issue an immediate referral to https://somedomain.com What good is an SSL cert on somedomain.com since a MiM attack can intercept the initial http:// query and issue a redirect to somewhere else? It will never hit the redirect on the web server.

Until web browsers START with substituting https:// instead of http:// on an unknown URL typed into the URL window, you can forget the security stuff. As I said, https makes sense on transactional sites where they are asking for passwords, or there's back and forth interaction. But basic yellow pages sites? Hardly. If I see a URL on the back of a plumbers truck for Mr Smiths Plumbing and type it in, then call the telephone number on the site I'm going to know I'm dealing with a fake if I don't get Mr Smith, or Mr Smith doesn't show up with Mr Smith business cards to unplug my toilet. (and if he does, the REAL Mr Smith can file a civil suit against him when he gets wind of this)

The key with all of this is looking at where does the money pass? If the site is nothing more than a way to move the interaction to face-to-face, which is what a Yellow Pages site is, then no attacker is going to waste time with a MiM attack. If you are looking for decorative stone an attacker is not going to gain by redirecting you to show up in the parking lot of a Denny's with your pickup looking for a pallet of rocks instead of showing up at the quarry. The transaction will have moved out of cyberspace long before folding green makes an appearance.

It's the sites where people are buying stuff online that are vulnerable to a MiM where the money changes hands over the Internet.

As for securing your server well that has nothing to do with whether or not you are running SSL and everything to do with whether or not you are running current versions of apache/ngx/whatever. Don't conflate the two. Putting a cert on old server code does NOT secure your server.

But, all of this is really sort of stupid and academic. The number #1 way that people get broken into today - and I'm speaking from REAL experience with customers - is phishing schemes via email. The users either click on a link in the mail message or just do whatever the mail message says, thinking it's legit. For example I had a customer taken in a wire fraud scheme 2 years ago for $43,000 because he got an email "from the CEO" which on review was observed to come from a spam message that was a duplicate domain name sender EXCEPT the domain name was 1 letter off. No SSL cert would have helped that. If anything it would have reinforced the belief it was a legitimate sender. I've had other customers fall for and nearly fall for phishing schemes and I get at least 1 email a month forwarded to me from a customer asking "is this legit" and that's from the ones that I've given the phish lecture to and instructed to forward anything questionable to me, and they are pretty good at spotting the fakes.

And we are FAR from getting SSL integrated into email, far FAR from it. Even the places that are sending and receiving TLS email between servers (I'm not talking client/server stuff I'm talking server/server stuff) half of them are probably still using that silly "Snake Oil Salesman" example cert that OpenSSL distributes. And all of the orgs -requiring- incoming TLS mail will happily accept a self-signed cert.

I use the LetsEncrypt certs for TLS smtp/imap/pop3 so that someone pulling out a phone in a "free wifi" area cannot have their password sniffed by the creep in the corner who is going to break into their email account and use it to relay spam, or check all of the major banks to see if they used that same password and empty their savings accounts if they did. For sites that require server-to-server incoming TLS mail the cert that is presented to them is a LetsEncrypt one - but I know from experience all those sites requiring TLS mail don't check that the cert is legitimate just that it's present. So please spare me the lectures on how SSL certs are oh so valuable in data integrity - the applications where that is the most important - email and knocking down spammers - they ignore that part of it. Maybe they will "get around to it" one of these days but there's currently a hell of a lot of round tuits needed.......

17

HSTS preload

If the destination isn't https with a matching certificate for the host name, any modern browser will recognize this. I wouldn't proceed. Would you?

This isn't 1990. Destroying reputations online is big business.

Agreed. Still not a reason to walk outside without clothes.

As for the rest, while I agree with much of what you say, to me it's a bit like arguing against dog leashes because they don't prevent forest fires.

3 Likes
18

May be coming sooner than you think:

But yes, it will fall back to HTTP if HTTPS is blocked by an attacker, and doesn't solve everything. HTTPS doesn't solve all the problems, but it helps mitigate some of them.

4 Likes
19

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