@scottalanmiller said in Ubuntu 19.04 upgraded from 18.10 - Meshcentral not redirecting port 80: @pmoncho said in Ubuntu 19.04 upgraded from 18.10 - Meshcentral not redirecting port 80: @scottalanmiller said in Ubuntu 19.04 upgraded from 18.10 - Meshcentral not redirecting port 80: @pmoncho said in Ubuntu 19.04 upgraded from 18.10 - Meshcentral not redirecting port 80: I would need to move it outside of home dir to something like /opt? Should, of course. No software ever goes in the /home directory. But need to? No, root can use any directory. Will work on this. Thanks If you are using NeDB, it is super simple to move the data file. If you are using MongoDB, the database is always still there on the same port. Until MongoDB is gone!

@IRJ This would be a heck of a guide if you ever get the time to do it

@JaredBusch said in WordPress admin page redirecting to IP: Is the site URL correct in the settings Been there many times

@scottalanmiller said in Let's Encrypt Windows Server: @WLS-ITGuy said in Let's Encrypt Windows Server: @JaredBusch you don't have any issues with agents checking in or pushing out updates with the RP? What would be the concern? Curious more than anything.

@JaredBusch said in MeshCentral LE production cert: @FATeknollogee said in MeshCentral LE production cert: @pmoncho said in MeshCentral LE production cert: @scottalanmiller said in MeshCentral LE production cert: @JaredBusch said in MeshCentral LE production cert: @scottalanmiller said in MeshCentral LE production cert: Oh weird, it was flawless transitioning for us. Did you let it restart on its own or did you manually restart the service? You have to restart the service anytime you change a setting in the config file. You aren't supposed to have to. Or at least you weren't supposed to have to in the past. It was supposed to detect changes and reload on its own. Did you try removing the letsencrypt folder prior to restarting for production mode? I had to do that too, along a couple other things that are now fixed. This was the fix?? Yes.

@EddieJennings said in Zimbra Certbot Scripts: Since acquiring and renewing a certificate can be automated with Certbot, would it make sense to have the cert in two places? HTTP/HTTPS traffic passes through your ngingX VM, which receives its certificate through its own instance of Certbot. And you have a second instance of certbot that functions on the Zimbra server itself, so you have a cert for IMAP and SMTP connections. Or, for you, does it not matter that IMAP and SMTP connections are unencrypted? Since beyond your own mail server, there's no guarantee that encrypted connections will exist. You could, but it would still be such a pain to automate as certbot can't renew the certs alone for Zimbra, that you might as well just use one.

https://drive.google.com/drive/folders/11AyoZGllxZ5tenyMQ2_b1DDo7c2-Znhc?usp=sharing

@wirestyle22 so much to work on....

Nice Guide! I did this all and automated it for LXQ

EMC shows it is assigned to all services and the schedule task is there. Calling this a win.

@phlipelder said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @scottalanmiller said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @phlipelder said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @scottalanmiller said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @phlipelder said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @jaredbusch said in Get Wildcard SSL Certs for IIS on Windows with LetsEncrypt: @scottalanmiller my problem with Certs on Windows, in general, is that you almost always have to copy it around to multiple servers to make everything work well, and that jsut defeats the purpose of LE. Based on what is on the site, Microsoft has an intrinsic trust with LE's root store. I should be able to set up a RD Session Host with a LE certificate for publishing and there should be no untrusted publisher for RemoteApps or Session Host desktops once the certificate's thumbprint is published via Group Policy? One would hope that they would. LE is like the standard in SSL Certs. It's from the EFF, way more trustworthy than other cert authorities, IMHO. Snag: Valid for 90 days. In larger RDS farm settings this would be a bear to manage. That means the need for an automated process. It is expected to be automated. SSL Cert updates should not be intrusive. All of the tools for LE SSL Certs are designed around the idea that you will automate them and never need to worry about them again. It's about being less of a snag, not more of one. Got it thanks. Looks like a bit of a learning curve then. It's not bad. I find learning the LE pieces easier than learning to do it the old fashioned way And with LE it is "learn once and ignore", rather than "learn once, forget, do again in a year or two all over again."

@stacksofplates said in Looking to migrate Nginx and LetsEncrypt: @jaredbusch said in Looking to migrate Nginx and LetsEncrypt: @stacksofplates said in Looking to migrate Nginx and LetsEncrypt: If you start over with a new system so you still get notifications of old certs expiring? Aren't these handled at the domain level so it knows that a new system has a newer cert? Honestly asking since I haven't run into this yet. No. It is handled on the cert serial number level. Ah ok. I've moved things in the past by simply reissuing on the new server, and dealing with the expiring certs is an annoyance.

https://xen-orchestra.com/docs/reverse_proxy.html Add this link to the readme?

@jaredbusch said in Remote Desktop Services & Lets Encrypt: @stuartjordan said in Remote Desktop Services & Lets Encrypt: There is also one for Exchange as well: https://mediarealm.com.au/articles/lets-encrypt-microsoft-exchange-installation/ Man, I just do not think I can trust all the pieces involved here to properly work together in an automated fashion. Exchange is generally fine. LE is generally fine. The scripts are generally fine. But any single issue with one will blow crap up. I think it'd still be worth a look. It could work out to be a nice time saver to set it up once and not have to worry about it.

Thanks @JaredBusch this will be a huge help! I'll give this a try later this evening when I'm back.

@zachary715 said in Certbot Apache plugin broken in Fedora 26: @scottalanmiller said in Certbot Apache plugin broken in Fedora 26: I ran into this issue, forgot about this thread, went through LetsEncrypt's threads and their solution for this problem led me... here! Very nice. Just did the exact same thing. Let'sEncrypt forum had the link which led me here right about the time @JaredBusch was responding in my other thread. It has been posted on here more than one time. I should probably find one of those posts and make @scottalanmiller tag it appropriately. Edit: Or too slow..

@NashBrydges Oh this is awesome! Gonna be giving that a go on Monday or Tuesday.

@JaredBusch said in Looking for how-to on setting up a proxy: server { client_max_body_size 40M; listen 80; server_name support.bundystl.com; rewrite ^ https://$server_name$request_uri? permanent; } Yep, got all that done and it's working well. What I was referring to was redirecting traffic to HTTPS. Essentially this is the part of the file I was missing... server { client_max_body_size 40M; listen 80; server_name support.bundystl.com; rewrite ^ https://$server_name$request_uri? permanent; }

This way you can share the config(s) under conf.d between multiple machines using the same roles (or whatever Salt calls them) and have different main NGINX server settings.

There is a blacklist that all CA's have on high dollar domain names to prevent major fraud. LE cannot issue for something.microsoft.com or something.bestbuy.com for example. But the sub domain names used in these PayPal examples are all outside of that. They are all on valid (ish) TLD.

@travisdh1 said in SSL between a proxy and its target: @Dashrender said in SSL between a proxy and its target: @dafyre said in SSL between a proxy and its target: @scottalanmiller said in SSL between a proxy and its target: Never had to do that. Seems like a script to pull it from time to time might be enough, though? Set up a passwordless scp of the /etc/letsencrypt (or /etc/certbot?) folder from the proxy to the internal machine? Any security risk to this? I don't know anything about it - I just see passwordless and have to ask. It's industry standard public/private key encryption, so shouldn't be an issue. You should go read up on SQRL. In my not so humble opinion, passwords have long outlived the point where they are a useful security mechanism. I'm fully aware of SQRL - I asked Scott on Day one of ML if he would support it when it became available, sadly it's still not released to the wild

@scottalanmiller said in Let's Encrypt stats: @Jason said in Let's Encrypt stats: I'm guessing a lot of kids/teens and college age are using let's encrpyt hence the .ninja I'm confused, aren't all those domains only used by ninjas? Go Ninja, Go Ninja, Go!

@Ambarishrh First of all, I welcome you to Cloudways.com. I'm Mustaasam, the WordPress Community Manager at Cloudways. I've tested your site on Tools Pingdom, the first hit was about 2.6 seconds and in 5th attempt it was loaded in just 1.07s. Here is the URL: https://tools.pingdom.com/#!/bNYY17/https://www.ambarishrh.com/

Yeah, that's a really awesome feature.

@scottalanmiller said in Let's Encrypt is now used around 4.86%: Yeah, probably a lot less than a year before LE rules the roost. Maybe four more months? In a year it will have significant dominance, I am guessing. More likely about this time next year because they did not come out of beta until March

Found it, nevermind.....

@scottalanmiller said: @Ambarishrh said: Wanted to setup Let's Encrypt for my blog which is now hosted on ASO but as per their tech agent, this is not possible! Is that because SSL is not offered at all? As per them, its only on dedicated servers and not shared. But using https://gethttpsforfree.com/ i was able to generate certs and install

@tonyshowoff said: @scottalanmiller said: @tonyshowoff said: @Dashrender said: @scottalanmiller said: @Dashrender said: Frankly, I'm frustrated that ICANN has allows so many registrars and SSL cert providers. There are over 1400 CAs trusted by Windows in 2010. Any one of those CAs can be compromised and their root cert used to sign fake certs for any site on the internet, instantly having Windows trust those certs. The whole security model on the internet is just broken. We don't have secure DNS or reliable Certificate Pinning. It would be a monopoly if they didn't make it basically open. Or monopoly-ish. Not an open market. Frankly, in this case, a monopoly, like you want for healthcare, seems like the better play. The fees should either be free or extremely low, only enough to handle the costs of administration and hardware required. Universal coverage does not imply monopolistic treatment. Further, most countries with universal health coverage also have private systems too. Like Panama... good healthcare for free or suckers can pay for private American healthcare from Johns Hopkins. Or Bosnia, the only place I know of where the "free" is way worse than private to an insane degree, and that's because of a war so at least that's an excuse. Johns Hopkins is the hospital that thought that nut job who thinks the pyramids were grain stores and all kinds of whacky things led their surgical department. You'd have to be insane to get treated at a hospital letting crazies like that even work there let alone run departments. (Working there as a janitor would be okay, just not in healthcare portions of the business.) That's the kind of hospital that removes your spleen because "if God wanted you to have it, he'd not have made it make you sick." Those people scare me.