Date/Time issue?

@FATeknollogee said in Setup a Cloudflare Origin Certificate for use on a backend server: @scottalanmiller said in Setup a Cloudflare Origin Certificate for use on a backend server: @FATeknollogee said in Setup a Cloudflare Origin Certificate for use on a backend server: noob question here: If you're hosting on Cloudflare, this should be used instead of LE? Not about "should", it's about which makes more sense for you in a given situation. "could" would probably have been a better word choice. Yup, you definitely can

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

Found this which didn't help, but could be a useful reference in the future... OpenSSL Convert PEM Convert PEM to DER openssl x509 -outform der -in certificate.pem -out certificate.der Convert PEM to P7B openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer Convert PEM to PFX openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt OpenSSL Convert DER Convert DER to PEM openssl x509 -inform der -in certificate.cer -out certificate.pem OpenSSL Convert P7B Convert P7B to PEM openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer Convert P7B to PFX openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer OpenSSL Convert PFX Convert PFX to PEM openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

@black3dynamite said in NGINX Reverse Proxy Help - Error code: SSL_ERROR_RX_RECORD_TOO_LONG: In the server block, add ssl_protocols TLSv1.2; and reload nginx no joy. Incognito mode did not work either.

@dafyre said in Fedora 29 Apache HTTPD Keeps Adding ssl.conf: Have you tried creating a blank ssl.conf file and then chmod +i ssl.conf ? I've not, but that's such a hockie way of doing it, I was hoping not to.

@dustinb3403 said in Do you setup SSL for Intranet websites only: Near-zero value in someone attacking is what I meant. Not a zero-value in what is provided by the systems. Also there is nothing confidential or needing "security" from a business perspective, which is why I ask is SSL worth it for these types of Intranet sites? You need SSL for everything period. Even if it's a self-signed cert it's fine... just allow the exception in the web browser and be done, or use an internal certificate if your browsers are set to trust the root... or a domain wildcard cert would work just fine. It's easy to do. You could set out a reverse proxy for use with Let's Encrypt, and use the reverse proxy for all of your internal-only web servers. On the reverse proxy, you can limit each site config to only pass internal IPs only. That's what I did for a few. For example, if you add this in: allow 10.0.0.0/8; allow 172.16.0.0/12; allow 192.168.0.0/16; deny all; It will not proxy anything unless it comes from an internal IP.

@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."

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

@psx_defector said in IIS Security setup: Best practice isn't up to date. Set it to PCI 1.2, that disables TLS1.0, all the AES stuff, etc. etc. You can also disable them manually in the first screen. Great, thanks.

I had some confusion because of the age of the old CSR. It doesn't line up with the correct dates. I'll edit my original post when I know more.

I had the same problem: Microsoft includes a command-line utility with Certificate Services called certutil. This utility performs various operations on certificate files, including converting them to and from base64 format. Note that this command is run on your certificate server, which, in your environment, may be different from your Exchange server. If so, you need to copy the binary .req file to the certificate server, or make it accessible via a shared network folder or removable storage device. Open a command prompt on the certificate server and navigate to the folder where your binary .req file is, then type the following command: certutil -encode yourbinaryinputfile yourasciioutputfile Example: certutil -encode der.exchange.example.com.req pem.exchange.example.com.req You can then open the output file in Notepad and confirm that it is in the correct format to upload to your certifying authority.

@travisdh1 Sometimes you never know!

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

@aaronstuder said in How to setup Nginx TLS certificate based Authentication (VPN alternative): @emad-r 3650 One of the main reasons that normal certs cannot be bought with forever expiration is because then people would be less apt to update them as ciphers are broken. Look at how many people still use(d) SSLv1 SHA1, etc., long after they were proven broken.

@zubairkhanzhk you're welcome!

@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..

@JaredBusch said in OpenSSL CSR with Subject Alternative Name: @EddieJennings said in OpenSSL CSR with Subject Alternative Name: @JaredBusch Correct. The "ye olde way" is how I've typically made a CSR and private key. The link I included talks about making a configuration file, which allows you to include SAN in your CSR. Ah, did not read the link. Yes, using a config file is the only method to get any SAN on a cert with OpenSSL. And after re-reading my post, I realized how terrible it was :(. I was hoping to find a one liner kind of thing, but alas. That particular article made it clear how to do it.

For anyone not familiar, here is a screenshot of my free version. here is a paid version at a client with ~40 extensions. (intentionally not all are shown such as the Snom PA-1 paging adapter, because I know someone will count....)

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

@StrongBad said in DNS record will help prevent unauthorized SSL certificates: Not a bad idea, I guess. There is some security concern there. I would wonder how often this is really an issue. Is this common? Or just proactive? I'm thinking a bit of both.

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 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!

https://www.data-vocabulary.org/ - Works. https://schema.org/ - Works

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