Order of operations help with getting a cert installed

Help
#1

Thanks to some inadvertent free time I found myself with this December I'm finally getting around to getting certs for my website (see my first thread about this here). I'm also attempting to go at this alone (that is, without my webmaster's help) because I hope that this will help me write a document on how someone with my level of expertise (ha!) can easily get an LE cert for their site.

My current issue is that I know that I've got mixed content on my site and need to get all of that sorted out first. I'm also thinking of redesigning my site completely so that the posts which may feature mixed content may no longer even be part of the site at all anymore.

In designing this project for myself, would you recommend I wipe everything, choose my new WP template and install it, do the cert stuff, then load in all of the WP posts that I actually want to keep and deal with the mixed content issues when loading the posts back in? Or should I load in all the WP posts I want to keep and deal with the mixed content issues first and then do the cert stuff?

---BEGIN COMPLETED FORM---

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: www.geekingoutabout.com

I ran this command: N/A

It produced this output: N/A

My web server is (include version): I don't know.

The operating system my web server runs on is (include version): Linux?

My hosting provider, if applicable, is: Sandwich.net

I can login to a root shell on my machine (yes or no, or I don't know): I don't know

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): It's a Word Press install?

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A

3 Likes
#2

Hello again :smiley:

:partying_face:

We're always happy to hear that here!

I sense a testimonial coming. I like it!

You don't necessarily need to go through a whole redesign specially for encryption, but we of the security-oriented persuasion will always encourage a security-first mindset.

IMO, you don't necessarily need to deal with the mixed content issues first because utilizing a cert and switching to HTTPS gets you so much bang for so little comparative effort. The Pareto principle if you will. The former method of starting fresh then addressing while loading up will be more organized and ensure the result without having to perform a complete or spot-check audit with the latter method.

certificate history:
https://crt.sh/?q=geekingoutabout.com

Your DNS looks alright. No DNSSEC, but that's alright for now.

https://dnsviz.net/d/geekingoutabout.com/dnssec/

4 Likes
#3

Sounds good to me. I'll admit that I am a little scared of the idea of nuking the content and starting from scratch but if that's what I have to do, that's what I have to do. I'm also noting here that I need to make sure that in my doc, I'll probably want to explain why I chose this method for the timeframe for this project.

Okay, why did you check this? What was the purpose?

What are you looking for when you do this and why?

2 Likes
#4

It's kinda like a certificate birth record sheet in a context like this. Certificate transparency (CT) logs (and gatherers like https://crt.sh) are how the public knows of the existence of your certificate (aside from it being served by your webserver, of course). We usually use https://crt.sh to know when a certificate has been successfully generated both to congratulate the certificate's owner as well as to indicate that all further troubleshooting should be directed towards certificate installation since certificate acquisition was clearly successful. Presence in CT logs is proof-positive of successful generation. Note that two certificates will be present: the precertificate and the leaf certificate. The latter is the "real" certificate.

This is checking for proper signing of the DNS records for DNSSEC. Admittedly, this is not academically/practically my strongest area, which I hope to rectify in the near future. Using a tool like https://DNSViz.net gives a graphical mapping of what is (or is not) happening to help troubleshoot in the future.

https://datatracker.ietf.org/doc/html/rfc4033

I also ran:

https://www.redirect-checker.org/index.php

on both the HTTP and HTTPS versions of geekingoutabout.com. The HTTP version of the apex (geekingoutabout.com) currently redirects (via WP) to the HTTP version of www.geekingoutabout.com, but the HTTPS version of the apex does not redirect. Ideally, the apex and www of HTTP and the apex of HTTPS should all redirect to the www of HTTPS to establish a canonical domain name for search engines. Otherwise, search engines might treat the apex and www accesses of your website as separate sites, thus splitting your traffic and hits between the two.

I ran:

https://www.missingpadlock.com/

to check the current mixed content status. A lot of the mixed content I see centers around Javascript references. Once you update the site URLs to have HTTPS, many of these may resolve themselves due to WP rewriting the mixed URLs.

3 Likes
#5

I'd separate these activities myself, but I don't know as it matters which order you go in. Hopefully updating http: to https: everywhere is fairly straightforward, and I thought there were Wordpress plugins out there to help with doing so. Then all you need to do is test that those pages using those previously-http: resources still work. And you probably want to address those before updating your site itself.

But re-working your site and modifying content really isn't related to this security, and I think it more just project management question for how you'd prefer to work. If it gives you less pages to test and you want to do it first, that seems fine. If you'd rather update everything to https and reorganize your site sometime later, that seems fine to me too.

Well, a lot of the time here, people are having trouble getting a certificate because their site doesn't actually work at all (for some or many people), but they don't realize it. In particular, sometimes servers are misconfigured for DNSSEC, or misconfigured for systems accessing over IPv6, or not answering DNS queries correctly at all. So it's a useful thing to check, to ensure that people all over the Internet using the current standards (like, say, Let's Encrypt's servers that check your domain) can actually get to it.

5 Likes
#6

What's your personal reason why you'd separate the tasks? I also think that since I'm going to be writing about my experience doing this, it does matter what order I do the tasks.

Other people in other threads have mentioned them and yes, I will be going back to those threads to pick up those tips.

Ah, something that I'll be doing when I'm actually doing the techie thing, got it.

2 Likes
#7

Also, does anyone mind if I use this post to continue to ask questions once I've resolved how I'm designing this project? Or would it be better to mark a solution, then start a new thread if I run into trouble?

2 Likes
#8

Hmm… I guess just because changing http: to https: is something I could do kinda mindlessly in batches (whether updating manually or through some sort of database update), perhaps will doing other things in the background, whereas thinking of what content I want on my site would require my brain to be more fully engaged. But if someone else wanted to do them together, I certainly wouldn't call it wrong. Again, it's more just about how you want to organize the project than anything security-related.

4 Likes
#9

Looking at the title, I'd say - just stick to that theme and your fine.
If it strays too far, and actually brings up and resolves some other completely unrelated issue(s)...
Then we may need to split part off.
[to ease the indexing/searching job of those that may come looking for such answer(s) - SEO].

5 Likes
#10

There shouldn't be a need to manually or programmatically or pluginatically change http to https. The article to which I linked identifies the two WordPress settings that need to be changed to handle the http to https url switches automatically and provides several ways of changing those settings.

There's also an upgrade header available that will automatically upgrade all http requests to https for content, which generally avoids the mixed content issue completely.

5 Likes
#11

I've managed multiple high traffic publishers and overseen dozens of CMS migrations. The odds of needing to drop posts/articles are incredibly small.

Most mixed content issues happen from these three things:

  • Templates (most issues)
  • Embedded Content within Posts/Articles (few issues)
  • Plugins triggered by content in posts/articles (rare issues)

To fix 99% of mixed content issues:

Templates: Use relative URLs for assets on the same domain. If pointing elsewhere, then specify https (preferred) or use the "same protocol" prefix.

Content: Mixed Content will only be triggered when the content is embeds (graphics, widgets, embed tags), not simple links. You can find these in most CMS systems with a simple search. There are often plugins available to analyze and update your content. This can also be examined and fixed in the database.

Plugins: Sometimes a plugin will take a "shortcode" and upgrade that to a widget. Make sure your plugins are up-to-date, and either use modern https urls in their templates, or use the "same protocol" prefix. If your plugin is not longer maintained, there may be a replacement made by someone else.

5 Likes
#12

All good things to keep in mind, thank you.

2 Likes
#13

Okay, I believe I've got an initial order of operations set and this is what I decided to go with:

  1. Export all existing WP posts to an .xml file.
  2. Make sure that all of the plugins I want to keep and want to keep on while I'm updating everything are also up to date.
  3. Have my webmaster upgrade my .php to the latest version.
  4. Delete every post except for a "Site maintenance" one.
  5. Delete the themes I'm not using or not investigating and FTP the theme I want into the right places.
  6. Start the cert-getting process.

Sweet, here's hoping I don't run into any other issues.

3 Likes
#14

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