Yaaaay 😃 I can't wait for this feature to land in production.

As far as I can see, this feature prefers to use only one Certificate for all the sites, opposed to LocalWP which creates one for each site. This is already better.

Trying to help somehow, I've built this branch and started a new WP instance with HTTPS checked. On my end, macOS, the site is not accessible(ERR_CONNECTION_CLOSED) even if I trust the certificate. After I find how to debug PHP/nginx logs, I'll be back with more details. <- scratch this, it was a port conflict with LocalWp.

Some feedback about the Your connection is not private warning when the certificate is not trusted yet. Some people might not know how to deal with it, and the small notice on the site creation is not enough. Maybe we can put another alert box in the Overview tab to inform the user that they haven't trusted the certificate yet?
I'm pretty sure this error can be matched when the Theme preview thumbnail is updated.

As far as I can see, this feature prefers to use only one Certificate for all the sites, opposed to LocalWP which creates one for each site. This is already better.

This might work similarly to Local (although I don't know Local very well). You have to trust what is called the "root" certificate but we do generate a certificate for each site internally, but they will just work when you trust the "root" certificate.

Let’s add a row to the Settings tab that shows if SSL is enabled. If it is, we should display a Trust link that shows a modal with the instructions for trusting the certificate.

I'll add a row to just show the value but no link at the moment. We need a generic solution to be able to change the url of the WP site. We should create a dedicate issue for that. It applies to both changing the domain and when you trust/untrust a site.

Perhaps we could show these instructions in the site creation modal once you click the link instead?

Do you mean show the instructions inline? I can do that, I'm wondering if it's too much information inline though.

@youknowriad Yes. We can keep the existing link, then show the instructions inline once it’s clicked.

Is this what you had in mind @matt-west ? I find it a bit weird that you have to click and scroll multiple times. What if instead we keep the dialog but ensure it stays open when you open the certificate.

Let me know what you prefer.

@youknowriad Yes, that’s what I thinking. I agree that it feels a bit to have all these extra section appear though.

If we can keep the dialog open, that’s a good compromise.

Something that I think is worth trying in the certificate manager:

1. Generate a Root CA, self-sign it, and trust it system-wide
2. Using the Root CA, generate an Intermediate CA restricted to only issue certificates in the *.wp.local domain
3. Delete the Root CA's private key
4. Ensure the Intermediate CA's files are only accessible to the user (chmod -go $f)
5. From that moment on, only use the Intermediate CA to issue/manage local sites' certificates

First I thought of simply setting chmod 000 on the Root CA, but now I think it's worth trying this more drastic approach. It seems to me that, theoretically, this would guarantee that any unwanted access to these keys could only be used to impersonate Studio sites, nothing else.

I believe the procedure goes like this:

• Issue a Root CA, as we already do
• Generate a private key for the Intermediate CA
• Create a Certificate Signing Request (CSR) for the Intermediate CA:
  • Set up a configuration including the Subject Alternative Name (SAN) extension for *.wp.local
  • Generate a CSR for that configuration
• Sign the Intermediate CA's CSR with the Root CA
  • In OpenSSL, the new CA can be verified with openssl x509 -in intermediateCA.crt -noout -text, which should reveal the correct SAN
• Hopefully, then, delete the Root CA's private key

Testing this again, it feels like there are way too many pop-ups if I try to trust the certificate while creating the site. I get lost in all the different dialogs and windows that appear.

I don’t think we should introduce the flow for trusting a certificate as part of the site creation flow. Instead this link should open the browser with a help doc containing the instructions. I can easily keep that alongside Studio while I set up the site, whereas the current dialog prevents me from interacting with the Studio UI.

We then need a link on the site settings tab to open the certificate file. We can include a brief explanation of why the certificate needs to be trusted and a link to the help doc too.

Is this possible @youknowriad?

A link on the site settings tab is possible but only after this other PR lands #1064 :)

@youknowriad Why? That PR allows you to change the custom domain, but my suggestion is just to display the "Trust certificate" link + copy for sites that already have SSL enabled. We would hide it for sites that don’t have SSL enabled.

We can follow up in another PR to add the ability to enable SSL on an existing site.

@mcsf, your proposal seems quite sound, but two questions popped up for me:

1. Do we need the intermediate certificate? Can't we put the same domain restrictions on the root certificate?
2. If we make it so *.wp.local are the only domains that support HTTPS, we'd need to update the custom domains feature accordingly. I think this is a reasonable limitation from a security perspective, but we need to consider this from a UI standpoint, @youknowriad.

@matt-west because that PR introduces the code that updates the domain name when you edit site settings which is required when the url moves from http to https.

That PR allows you to change the custom domain, but my suggestion is just to display the "Trust certificate" link + copy for sites that already have SSL enabled. We would hide it for sites that don’t have SSL enabled.

So you're saying we should keep the "toggle" on the creation modal, I thought you wanted to remove it from there. Ok, yes, this change we can do here, without waiting for the other PR :) Sorry for the confusion.

When the domain is not under wp.local, the Overview screen is rendered as if it is still loading, with flashing placeholders (see screenshot below).

I can't reproduce this.

There is nothing either preventing or explaining to the user what happens when they choose a non-wp.local domain with SSL enabled.

Yes, this is pending a decision above, either limit the creation of such domains or add a message.

Site initialisation is feeling a lot slower to me (and on a new machine). I can't guarantee it's directly tied to this PR, or its original base (custom domains), or just a coincidence.

I've noticed this before in other PRs too.

Seems like all the comments are addressed. The last blocker is a decision on what to do here https://github.com/Automattic/studio/pull/1034/files/cbbabe32b15459d1e8a7ac0a72e59f58c6eb46ad#diff-e2be6df548f75063abd8db0f241c35626f7af6a1c6a10c429935de5f902dbbc6

I can't reproduce this.

Was that before making the change to src/screenshot-window.ts?

I can't reproduce this.

Was that before making the change to src/screenshot-window.ts?

You're right, the issue is gone. ✅

This is a significant change! 🥳 I haven't looked into code much yet, but I reviewed the discussion and tried to approach it as a general Studio user:

1. Start Studio
2. Click 'Add site', enable custom domain and HTTPS
3. Provide the password to let Studio add a hosts entry
4. Click a screenshot to open the site

The site is started, opens in the browser, and displays a certificate error. I was not sure how to proceed further.

As I read the thread above and found some clues, I navigated to Settings and located "HTTP Enabled Trust Certificate. I opened a .crtfile and was asked to add the certificate to a keychain. I approved, restarted the browser, and still couldn't make it work. Then, I tested Local's flow and discovered that I needed to locate my certificate in the keychain and mark it as trusted. I restarted the browser, and it works fine now.

Questions related to UX:

1. I can't see any easy transition from the "Add a site" step to the "Trust Certificate". The site starts and doesn't work in the browser. Should we automatically open Settings and highlight the part with the certificate when the user adds or starts a site configured to use HTTPS and the certificate is not trusted yet? Or display dialog asking user to do so?
2. Should we add a 'Learn more' link near the 'Enable HTTPS' field, what could also improve UX issue from the previous point?
3. I noticed that the Trust Certificate link and all instructions are hidden for sites with HTTPS disabled, which makes sense. Should we hide it also for those with HTTPS enabled when the certificate is already trusted?

I can't see any easy transition from the "Add a site" step to the "Trust Certificate". The site starts and doesn't work in the browser. Should we automatically open Settings and highlight the part with the certificate when the user adds or starts a site configured to use HTTPS and the certificate is not trusted yet? Or display dialog asking user to do so?

Displaying a dialog seems like a good approach. Trusting the certificate is required, and dialogs can't be missed. This could be a separate PR, because we only want to open that dialog when the root certificate isn't already trusted, and we need to figure out the best way for determining that.

Should we add a 'Learn more' link near the 'Enable HTTPS' field, what could also improve UX issue from the previous point?

I agree we should do this. I previously suggested adding an explainer text below that checkbox.

I noticed that the Trust Certificate link and all instructions are hidden for sites with HTTPS disabled, which makes sense. Should we hide it also for those with HTTPS enabled when the certificate is already trusted?

Seems like a good idea 👍 This could also be a follow-up PR together with the dialog that opens after adding or editing a site.

Since this PR is getting big and to track the improvements we can make later, I opened this follow-up issue to address the different points that require detection of whether the root certificate is trusted.

Thanks all for the help landing this. I'm very excited about this one. The project is not done yet, there's a few related issues, you can follow on Linear.