Is this community, for Let's Encrypt, mostly Windows and Linux centric vs FreeBSD and OpenBSD?
And other less high volume OSes too?
Thanks! 
8 Likes
In my experience, *nix OS's (including various restricted hosting platforms based on them) tend to be the most common. Windows tends to be next in line.
9 Likes
So @griffin you saying *BSDs and other Posix and real UNIXes are fairly well supported?
The reason I ask is I see a lot of sudo other linux style commands that are less common on other OSes. Such as ip route vs ifconfig.
5 Likes
What do you mean by "best help"?
I happen to think that most of the help here is exceptional [better than most other forums].
As for OSes covered ...
Anything that can run an ACME client would be included.
The largest amount of topics would surely go to Linux type systems then there are Windows and MACs too.
As for things like "ip route vs ifconfig" ...
Sometimes the person responding isn't very familiar with that OS but the troubleshooting is generally on point.
12 Likes
Many folks here (including myself) have experience on the BSDs, solaris, etc and would be able to help. If you're running a proprietary and more obscure OS like HP-UX or z/OS or something, you'd probably be less likely to get immediate on-point help. But then, chances are any user on more obscure systems is sufficiently familiar with them to deal with their quirks.
The support threads you see are going to be biased by where people are running systems and need help. Chances are people aren't sitting with an SGI Indy running IRIX but at the same time needing help with their OS.
You'll see a lot of what people need help with here isn't necessarily ACME itself, but with the firewalls, web servers, and surrounding infrastructure of their systems.
14 Likes
Good question @rg305, I mean easiest to get assistance with when I (or a customer) is seeking help for an ACME issue we are having.
5 Likes
Also: If you're running a more obscure platform and may be in need of more in-depth help, there are a number of people who are available for consulting services: Consultants who support Let's Encrypt
10 Likes
Probably Ubuntu 20 with apache is a site favorite.
[nginx seems NOT to have as many issues]
Actually anything with apache is further up the chart than any other web server.
Then there are the things that don't play well together or users just tend to "do it wrong":
TomcatBitnamiNextcloudZimbra- (any)Panel/Wordpress/NPM +
certbot
9 Likes
Thanks @mcpherrinm that is good to know.
I deal with embedded systems (IoT for example) the as tighter resource constraints than a typical server. Yet we need them secure and they use web interfaces to control them. Think of like a D-Link home router. So we don't have python, etc. Also linux out of memory killer, due to linux giving memroy to an application on use and NOT on request, is a big issue for us.
6 Likes
If you can securely upload/download files [I sure hope you do]...
You might do well with centralizing your cert management.
That way the end device need not know anything about the ACME protocol.
Only get cert and use cert.
10 Likes
@rg305 Thank you, that sounds helpful.
I'll research it; and possibly as intelligent, question here.
7 Likes
There probably are a few but I personally wouldn't be able to say "many"? Could be my memory is terrible tho.. Well, my memory is terrible, so could definitely be the cause, but I couldn't name users having much experience with those OSes to be honest.
On another note: I myself run a few Gentoo GNU/Linux systems, which is kinda an outcast among Linux distributions.. 
So proud of that 
9 Likes
Hi @Osiris true it my be an outcast, but it is still way more popular than an embedded roll your own linux distro link Yocto or others provide.
And https://openwrt.org also.
Thank you.
9 Likes
@barf7709 maybe you should have (or possibly still could edit) the title with something referring to embedded and / or IoT Operating Systems that need to provide web services while using an ACME environment. Just a thought. 
7 Likes
The bias/popularity on this site is driven by two things:
- OS Distribution
- Client Distribution
If you're dealing with embedded systems and odd constraints:
- The first thing you should look for is an existing client for your target operating system. The clients and operating system deployment are what requires
sudo, etc -- not the ACME protocol. - An extension of @rg305's suggestion is to procure the Certificates on a different machine, and then deploy them onto your targets.
- I opensourced our system of centralized certificate management, GitHub - aptise/peter_sslers: or how i stopped worrying and learned to love the ssl certificate, though the public version is out-of-date with our internal systems.
- If you can't find a suitable client and need to build your own, there are many client developers that are on this forum that can answer your questions and help guide you.
Randomly, I was moving some stuff around this weekend and unearthed my SGI 1600SW monitor. I keep it around for emergencies.
10 Likes
Thank you @jvanasco
One of the issues is trying to keep the odd constrains from interfering with security and support long term. Our customers, I speak of, are not end users but orginazations desiging the products for end users.
6 Likes
hmm...
Sounds like centralized certificate management may not pass "the audit phase".
That leaves only using the tiniest possible ACME client [or writing your own].
Unless I'm overlooking something...
8 Likes
@rg305 I don't belive you are overlooking any significant details. Your input and the others who have replied is very useful. Thank you!
8 Likes
I think the options are more limited. Considering the restrictions/concerns above, it's likely going to need to be one of the existing clients implemented in C (see ACME Client Implementations - Let's Encrypt for examples, which is just a subset of available clients) or writing their own client.
Reading across your comments, @barf7709, it sounds like you are maintaining a customized OS to be deployed on embedded systems. The smaller clients, which @rg305 referenced, are usually implemented in a scripting language (acme-tiny is Python) or shell scripts (e.g. acme.sh, dehydrated) - both of which will require certain executables to be available (e.g. sudo).
I think the most likely scenario with these constraints will be writing a custom client.
Since the devices are embedded (I've built and managed those too), I will note the following:
1- You will need a fallback option, for users to upload a certificate they procure using other means and then restart the relevant services.
2- You will need an OS upgrade option, to ensure users can upgrade their TLS settings and OpenSSL library (or equivalent) AS WELL AS the trusted root store. Upgrades to your client may be necessary too. Even though inbound connections for the test are done via simple HTTP, the outbound connections to the ACME server must be done via HTTPS. There was recently an issue in this forum with a user who manages a centralized service for an embedded systems company - the units in the wild had a mix of trust stores and ssl library versions. They did not run ACME clients on these units, but ran into other issues as many units could not connect to sites serving LetsEncrypt certificates. The troubles they had included:
- Units could not communicate with online services because they lacked a modern TLS version which destinations require. Note: ACME endpoints often require higher minimum TLS versions as standards change.
- Units could not communicate with online services because their Trust Store did not have Roots which LetsEncrypt supports.
10 Likes
Thank you everyone for your support and answers.
3 Likes