A simplified version of this guide just got merged into the official docs.

@flaxking said in SSL/TLS client certificates questions: Domain name doesn't matter, unless you're signing with a public CA. I'd think self-signed vs internal CA vs public CA would depend on what the authentication mechanism supports and how you have to manage the certificates. (i.e. if there are going to be a ton of them it might be easier for the authentication mechanism just to trust certificates signed by a certain internal CA rather than having to make each certificate trusted. From what I've seen so far, I've come to the same conclusion.

Didn't we have one of these threads last year? tags - please?

we use Kemp to publish Skype for Business and SharePoint. Their guides are excellent!

And this person has a full guide https://xcp-ng.org/forum/topic/3775/xen-orchestra-from-source-with-let-s-encrypt-certificates

@jaredbusch said in DNS-over-HTTPS with Fedora based PiHole and Cloudflare: The entire concept is just stupid. You cannot hide from your provider. I'd agree with you, at least for now. This is just one small step in the right direction. It won't really make much difference until it's supported by all endpoints.

Not particularly good, actually. Good to spread awaremenss, but the information was mostly spotty with a chance of confusion.

@tim_g Do you know what tools and scripts that is available when installing hyperv-tools?

@zubairkhanzhk you're welcome!

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.

@scottalanmiller Thanks Scott. That jogged my memory to enable ssl module. That was what I missed.

@Dashrender said: @scottalanmiller said: @Dashrender said: Now one might argue that the solution provider does take this into consideration and fully expects their customers to rebuy when "required to" because the underlying software is considered a security risk. But we all know that this is rarely if ever the case. Yes but... it makes it the customer's fault What's just as bad is often the vendor doesn't have a new solution either. No different than offering no solution at all. It means that the vendor no longer offers a supported product. Time to move on.

SSL and TLS protect people from spying on an existing communications channel, but does nothing to protect the end points. It's just a service that has to respond to any incoming request.