Potential Bugs with New SSL Certs (https)

Ferguson

I have an unusual problem, and it's conceivable it is something I am doing, but I think it is the new certs and code for it.

As I test I keep getting logged out (probably correct as switching protocols may do that, but not sure). I used to have a link taking me to the login page, which returned me to my home page. That was hard coded as HTTP (my bad, but another issue).

So I tried doing it by hand:

• go to https://smugmug.com
• Log out (just to be consistent)
• Log in
• Without asking, I'm no my home page in http mode.

Try again --

• go to https://smugmug.com
• This time I'm already logged in, do not log out
• Pull down the dropdown for the account and choose homepage
• I'm on my home page in http mode, not https

Try again with this link:

https://secure.smugmug.com/login?goTo=https://www.captivephotons.com/

Notice the https on the goto. I get the same behavior, I revert to http.

I think there's an explicit change from https to http in relation to logging in. I'm finding I actually can't get on https and be logged in.

This is part of the phased in approach, or is my account set up incorrectly? Or do I have some bad code somewhere?

Ferguson

With the new SSL certs, should we be concerned about these warnings from Chrome?

Note as best I know there's nothing in there in my code, but I could be wrong, I think it's all SM generated.

denisegoldberg

When I log in from https://www.smugmug.com I am taken to my homepage using https.
Unfortunately the page and entire site using https:// shows as if I'm not logged in.

If I revert to http:// then I see the site as logged in, with the smug header containing the usual commands and access to customization and account settings.

Logged in, on my homepage using https:// - https://www.denisegoldberg.com/

Logged in, on my homepage using http:// - http://www.denisegoldberg.com/

Clearly I can work around this issue by explicitly using http:// when editing, but this isn't right.

Ferguson

Yeah, posted here already: https://dgrin.com/discussion/263153/new-ssl-certs-logging-in-takes-you-out-of-https

Seems broken to me, but maybe they don't have all the tools yet working with SSL?

denisegoldberg

@Ferguson said:
Yeah, posted here already: https://dgrin.com/discussion/263153/new-ssl-certs-logging-in-takes-you-out-of-https

Seems broken to me, but maybe they don't have all the tools yet working with SSL?

Funny, I was going to add this to your thread but then I read it again and wasn't sure if it was the same issue - I didn't want to cause confusion.

@leftquark would you prefer that I roll this into @Ferguson thread or should I leave this as is?

Ferguson

@denisegoldberg said:

@Ferguson said:
Yeah, posted here already: https://dgrin.com/discussion/263153/new-ssl-certs-logging-in-takes-you-out-of-https

Seems broken to me, but maybe they don't have all the tools yet working with SSL?

Funny, I was going to add this to your thread but then I read it again and wasn't sure if it was the same issue - I didn't want to cause confusion.

@leftquark would you prefer that I roll this into @Ferguson thread or should I leave this as is?

I think it has the same origin, anything I do to get logged in takes me back to http. it's not just the customization screen, I can't even be logged in (e.g. to get-a-link, buy, etc.)

denisegoldberg

@Ferguson said:
I think it has the same origin, anything I do to get logged in takes me back to http. it's not just the customization screen, I can't even be logged in (e.g. to get-a-link, buy, etc.)

Ah, you're right. I can only request a share from http, and the share html uses http for my site.

leftquark

@Ferguson said:
With the new SSL certs, should we be concerned about these warnings from Chrome?

Note as best I know there's nothing in there in my code, but I could be wrong, I think it's all SM generated.

Good question and fortunately there's nothing to be concerned with here. Amazon controls most of those SSL certificates and should update those before they're distrusted.

leftquark

@denisegoldberg and @Ferguson: I've gone ahead and merged the 3 threads related to bugs into 1 thread and renamed it to "Potential Bugs with New SSL certs", so we can keep track of all issues here in one place.

leftquark

The issue with logging in / redirecting / appearing to be logged in is something we're working through (not intended). We tested this prior to launch, as much as we could, but the folks who had hacked SSL into their sites prevented us from diving in as deep as we would have liked prior to launch. This is one of the reasons why we're doing a slow roll-out of all custom domains and not moving everyone over on day 1 -- so we could identify any issues and close them quickly. Stay tuned!

Ferguson

@leftquark said:
The issue with logging in / redirecting / appearing to be logged in is something we're working through (not intended). We tested this prior to launch, as much as we could, but the folks who had hacked SSL into their sites prevented us from diving in as deep as we would have liked prior to launch. This is one of the reasons why we're doing a slow roll-out of all custom domains and not moving everyone over on day 1 -- so we could identify any issues and close them quickly. Stay tuned!

Thanks. If that implies the problem is only with sites who hacked SSL before, I never did, and have the issue. If that just is a lament about it complicating testing, never mind.

Once you understand it, it's not a big deal to avoid.

leftquark

Yea ... we would have preferred to silently push SSL live, test it and work out all the bugs, then enable it for all of you. However, that would have immediately broken the sites for the people who did the hack, which we wanted to avoid, so we lost our chance to work out the bugs earlier.

We'll get it fixed so you don't have to worry about it.

MarcQuinlivan

From looking at the certs, I can see that you have chosen one customer domain for the cert (The Issued To domain) and then added in a group of additional customer domains as SANs (Subject Alternative Names). I understand that this is being done to reduce the number of certs required and the cost.

The concern I have with this is that if somebody happens to view the cert for my domains they will see a random name in the issued to section and may get confused about the security of the site.

Is there a particular reason why the "Issued To" domain is not xxx.smugmug.com instead?

I have four Smugmug accounts and two of them are listed below:

www.marcquinlivan.photography shows as issued to www.livinglifephotography.com
www.alyxcoby.com shows as issued to photos.gdupphoto.com

Obviously the certs work and with my domain listed on the SAN for each cert the sites show as secure.

I know if I was a visitor to a site and happened to notice that the cert was issued to another domain I would check out that domain to see what it is. If I saw it was another photography business it would not look right, but if the issued to was xxx.smugmug.com and I went to that URL I would see that it is a photography hosting service.

It's not necessarily a major issue, but unless there's a technical reason why the cert cannot be issued to xxx.smugmug.com, wouldn't it make sense to do that?

(NOTE - xxx.smugmug.com is not the user's smugmug domain, but hostname Smugmug would use for issuing the certs.)

rainforest1155

Hi Marc,
We appreciated the detailed feedback on this new feature. This is just the first release and there'll be further improvements coming down the road.

Ferguson

@MarcQuinlivan said:
From looking at the certs, I can see that you have chosen one customer domain for the cert (The Issued To domain) and then added in a group of additional customer domains as SANs (Subject Alternative Names). I understand that this is being done to reduce the number of certs required and the cost.

I thought Let's Encrypt was free?

Now that I look, my site is owned by CassCollingsPhotography.com. That took two clicks to see on various browsers.

I dug through the details on Firefox and actually could not find my site's name.

I honestly do not know how much difference this makes, especially since I do not sell anything there, but it is very disconcerting to hear, and I suggest this decision needs to be reconsidered, or restructured. I would not care in the least if it had lead first to a Smugmug site, but getting someone else's business name to appear first is... well, let's go with disconcerting.

Hikin' Mike

@Ferguson said:
Now that I look, my site is owned by CassCollingsPhotography.com. That took two clicks to see on various browsers.

I looked at mine too. My galleries are SmugMug and I have a different owner then you (albertocaleboz.com).

leftquark

@MarcQuinlivan does touch on some of the rationale for how the certificates are generated. We wanted to get SSL certificates generated as quickly as possible and have a number of iterations planned to improve how we built this. We're working with Lets Encrypt to improve on this functionality. In the future the CN will point to a SM address.

(Side node: The CN is a deprecated field, but we do realize that a rare customer might inspect the cert and be surprised by that. However, your login and shopping cart certs which that the rare viewer would be more likely to view all use the smugmug domain for the CN).

Ferguson

@leftquark said:
(Side node: The CN is a deprecated field, but we do realize that a rare customer might inspect the cert and be surprised by that. However, your login and shopping cart certs which that the rare viewer would be more likely to view all use the smugmug domain for the CN).

And that's why I said "disconcerting". I think it is also fair to say that it is really important that this has happened, and that it appears to have happened with such minimal issues. It seems (at least to an outsider) huge compared to something like, oh, say... feature images, yet it has had relatively speaking very little problem. So Kudos to that effort.

Now., tell CassCollingsPhotography they owe me for letting them use my photos, $10,000 for each of the thousands of photos, and we'll call it even.

MarcQuinlivan

@leftquark said:
@MarcQuinlivan does touch on some of the rationale for how the certificates are generated. We wanted to get SSL certificates generated as quickly as possible and have a number of iterations planned to improve how we built this. We're working with Lets Encrypt to improve on this functionality. In the future the CN will point to a SM address.

(Side node: The CN is a deprecated field, but we do realize that a rare customer might inspect the cert and be surprised by that. However, your login and shopping cart certs which that the rare viewer would be more likely to view all use the smugmug domain for the CN).

Thanks - I figured there'd be further developments down the line.

I wanted to add my name to the SSL logout issue list, but my experience seems to be a bit different.

If I log in to my sites and then switch the URL to https I see my sites as if I am logged out (which has been reported above), but if I then go back to http I have to log in again. The reports above seem to suggest that going back to http displays the site as if the user is logged in.

MarcQuinlivan

@Ferguson said:
I dug through the details on Firefox and actually could not find my site's name.

I honestly do not know how much difference this makes, especially since I do not sell anything there, but it is very disconcerting to hear, and I suggest this decision needs to be reconsidered, or restructured. I would not care in the least if it had lead first to a Smugmug site, but getting someone else's business name to appear first is... well, let's go with disconcerting.

It's listed under "Subject Alternative Name" on the details tab.

denisegoldberg

I don't understand why the "issued to" isn't by default a smugmug url.

My site certificate also shows as issued to someone else, not smug, not me. That's wrong.
I expected to see the "issued to" as smugmug.

Just out of curiosity I checked my blog, and that certificate clearly shows as issued to Google (the owner of blogger); that one makes sense. And that implies that it is possible to have an "issued to" that reflects the organization that did the underlying certificate work as opposed to a site that is totally unrelated to my site.

rainforest1155

Denise, please see aaron's comment on this.

Djm3006

Q: what is the time line to have all this done?

Lille Ulven

Not certain if I have overread it but maybe this is another related bug then:
@leftquark you might remember that you had to talk to my domain host a while back to get the redirection from lilleulven.com to www.lilleulven.com to work for subdirectories? I can now see that while the redirect from http://lilleulven.com works nicely, the one from https://lilleulven.com tells me that the connection to the server lilleulven.com could not be established.
Oh: I never hacked my system into "using the at the time unavailable SSL" ;-)

Good luck with the fixes

Ferguson

@Lille Ulven said:
Not certain if I have overread it but maybe this is another related bug then:
@leftquark you might remember that you had to talk to my domain host a while back to get the redirection from lilleulven.com to www.lilleulven.com to work for subdirectories? I can now see that while the redirect from http://lilleulven.com works nicely, the one from https://lilleulven.com tells me that the connection to the server lilleulven.com could not be established.
Oh: I never hacked my system into "using the at the time unavailable SSL" ;-)

I get the same thing. I'm set (with Google Domains as the registrar) to give a 302 redirect to www. I'm not actually sure why i did 302 vs 301 years ago. And at one point I thought I just had an A record.

What's the right way to have a domain use the www-less form to get to Smugmug going forward? 301, 302, A/AAAA, or....?

leftquark

We were just talking about working on adding a help page to talk about www -> no www redirection, especially now that it has to be done for https as well. The DNS server would need to support the redirection on the https side as well, so you'd have to setup something similar to your www redirection. Since each host is different, I don't know the specific steps, but we're starting to investigate for the major providers like GoDaddy, Google, etc.

We're working on some fixes for the logging in/out issue (including when you switch from http to https / vice-versa). Hoping to have a fix for that out shortly.

The issues around CN/SAN require us to work with LetsEncrypt (which we're actively doing) and I don't have an ETA since it requires work on both our parts.

Lille Ulven

@leftquark OK, then I'll have a chat with the folks from my domain registrar and see if they can set up something similar for that redirection - plus the subfolder redirection for it as well.

Just got a reply from them which leaves me puzzled.
they say they cannot do the redirect because that would require them to host the SSL certificate and they do not offer hosting as a service. I can apparently do some very strange tricks and run this somehow from IwantMyName via GreenGeeks (blog host) to Smugmug and have the SSL cert hosted at GreenGeeks. Not sure how that would work...if at all.
But if I understand you right, @leftquark than smugmug is hosting those SSL certificates, is that correct?

leftquark

(Caveat: I'm not an expert on this but I think my understanding is accurate)

Basically the flow of traffic is like this:
For non-SSL: http://yourdomain.com -> Your Domain Host -> Look for direction and find "redirect to www" -> www then directs to SmugMug -> SM page loads

Things are a little different for SSL (https):
For SSL: https://yourdomain.com -> Your Domain Host -> look for secure cert -> if found, look for direction and find "redirect to www" -> www then redirects to SM -> SM page loads

The "look for direction" is the step where you've configured no-www to point to www.

SmugMug is only hosting the SSL certificate for the domain you've entered in your custom domain field, and it loads once your host has told it to look for SM. Since the first thing the browser does, before it's even told to look at SmugMug, is to verify the certificate (which your host would need to provide), you're getting those warnings. This is why the host said they would need to host the certificate.

Each domain host will do the redirection a little differently, so I won't know the exact steps to perform it. It appears on my own site, how I setup the no-www to www redirect, it also works perfectly for the https redirect. I'm not sure what's different about that setup from your host. I'd have to do some more investigation and haven't had a chance to do that.

BigRed

@leftquark said:
[SNIP]
Since the first thing the browser does, before it's even told to look at SmugMug, is to verify the certificate (which your host would need to provide), you're getting those warnings.

Thank you for explaining this new SSL redirect problem. Let's hope you can find a systemic approach to solving it, rather than needing to write instructions for every domain host, and then to depend on every custom domain holder to do their own CNAME maintenance (which is just about the least user-friendly thing there is).
And please note that https://yourdomain.com (no www) does a full stop in the browser, with a nasty error message -- it's not just a "warning."

Ferguson

I haven't tried, but will an A (or AAAA) record work as SM will do the redirect I think? Not cache friendly but if there's one landing IP ...?

Lille Ulven

@leftquark since your https://websiteWithoutLeadingWWW to https://WWWwebsite seems to work, could you write down here how you did it with your domain host (and what domain host you are using)? That way I could (and probably a few more of us) send your "recipe" to my domain host and ask them to translate that into their setup. If we then "collect" a list of who asks whom we might all be able to a) get the solutions and b) get the documentary for more or less all domain hosts done in no time.

Thanks

Lille Ulven