SSL Certificate for Main website - impact to Smugmug Pro Subdomain?

MomaZunk

I need to add an SSL certificate to my main domain and website. I currently have a subdomain "photos" for my smugmug pro site.

I am interested in what impact adding an SSL to my main site will have with my SM site since there is not an SSL on SM.

I understand that the SSL can extend to subdomains as well. Will this cause issues with SM?

I am assuming the ability to embed photos from SM to my main site could be impacted. Is this the case?

What else?

Anyone have any experience here good or bad?


TIA,

Ferguson

As I understand it (and hopefully Smugmug will confirm), it is not currently possible.

You can obtain a certificate for your domain (or specific host or subdomain) but it would have to be installed on Smugmug servers to function, and they do not support that. They can obtain a certificate, probably wildcard, (and I think are discussing it) for domains like nickname.smugmug.com, but have not.

So I think at this point it just can't be done.

There is a vote-able feature request here but it lacks any comments from Smugmug.

Postscript:

Also here and here

I guess there's no process to consolidate feature requests that are duplicates.

cabbey

Hey Dee,

As Ferguson said, you can't currently add a cert to your SmugMug site. However, I'm pretty sure that's not what you're talking about doing.

You can add a certificate to your main site, say 'www.example.com' and still have it direct to your subdomained account at something like 'photos.example.com'. Just make sure the certificate you get is ONLY for the main domain/site ('example.com' and 'www.example.com') and does NOT claim to be for your site's subdomain or SmugMug site. ('photos.example.com' or 'example.smugmug.com')

cabbey

MomaZunk wrote: »

I am assuming the ability to embed photos from SM to my main site could be impacted. Is this the case?

I forgot to address this one in my previous reply. There can be issues with embedding content... specifically if your page is served secure (via https) and you include content insecurely (via http) then your visitors will see warnings in many browsers that "portions of this site's content were loaded insecurely". (or words to that effect.)

You can work around this by editing the url you use for your embedded images to be

https://photos.smugmug.com/...

instead of

http://photos.example.com/...

or

http://example-nickname.smugmug.com/

Note that you can serve the secure form of the image in BOTH secure and insecure pages just fine... no one complains about loading secure content on an insecure page.

Ferguson

cabbey wrote: »

Hey Dee,

As Ferguson said, you can't currently add a cert to your SmugMug site. However, I'm pretty sure that's not what you're talking about doing.

You can add a certificate to your main site, say 'www.example.com' and still have it direct to your subdomained account at something like 'photos.example.com'. Just make sure the certificate you get is ONLY for the main domain/site ('example.com' and 'www.example.com') and does NOT claim to be for your site's subdomain or SmugMug site. ('photos.example.com' or 'example.smugmug.com')

Actually from a brief look I think that's exactly it. I think www.deezunkerphotography.com (and probably deezunkerphotography.com) are the main domain hosted elsewhere (address owed by websitewelcome.com whoever they are).

photos.deezunkerphotography.com is the smugmug account, and translates to the usual smugmug setup for custom domains.

To the OP, the issue is that Smugmug cannot get a cert in your name, or respond to SSL as though they had one; you can get a cert yourself but Smugmug would need to create a mechanism to load that into their servers (and CDN, not sure how that works), which they have not done.

Considering how much trouble people have with custom domains, as easy as that is, I can't imagine the help desk load of having people trying to do their own custom domain certs, so I also get why they may be reluctant. Though I think they really need to, eventually.

MomaZunk

Ferguson:
I have my main domain on a hosted site outside of Smugmug. I needed the ability to add iframes, paypal code for self fullfilling, and improve my SEO as well.
I wanted to add the SSL certificate for just my site, but was not sure the impact to the unsecured smugmug side.


So cabbey:
The embedding issue is exactly what I was concerned about.
So I can use the https: in place of the http: for my smugmug photos subdomain even though there is really not https?

Ferguson

MomaZunk wrote: »

So cabbey:
The embedding issue is exactly what I was concerned about.
So I can use the https: in place of the http: for my smugmug photos subdomain even though there is really not https?

I'm not cabbey, but no, not by your subdomain's name. You could use https://nickname.smugmug.com internally to link to it and it would work fine but if you use your domain it will trigger a "your connection is not private" or similar error because the name and the cert will not match.

Just enter it in the browser bar and you'll see. Depending on how you use it internally you may or may not see the same error (e.g. how it is embedded), but it will not work correctly.

cabbey

MomaZunk wrote: »

The embedding issue is exactly what I was concerned about.
So I can use the https: in place of the http: for my smugmug photos subdomain even though there is really not https?

Not quite. The 'photos' in those secure urls just happens to be the same name you used for your subdomain, but it's not there for that reason. My custom subdomain happens to be 'smug', but I would still use 'photos' to do this for my own website.

Let's take one of your images as an example. The direct image URL to embed a small of that photo would NORMALLY be:

http://photos.deezunkerphotography.com/Fine-Art-Prints/My-Neighborhood/i-FgB2mPL/1/S/120106_TDZ_0099_7DZ1910-Edit-S.jpg

If you do as Ferguson suggested, you would use your nickname and turn that into

https://zunker.smugmug.com/Fine-Art-Prints/My-Neighborhood/i-FgB2mPL/1/S/120106_TDZ_0099_7DZ1910-Edit-S.jpg

However, since you have a custom domain configured, that will cause us to redirect the browser to your custom domain, which can't be https currently and will cause the aforementioned mixed content warnings.

Instead, you'll need to pretend the gallery is hide owner and use photos.smugmug.com:

https://photos.smugmug.com/Fine-Art-Prints/My-Neighborhood/i-FgB2mPL/1/S/120106_TDZ_0099_7DZ1910-Edit-S.jpg

Eventually we'll bring out a more thorough https solution that will allow more of the above to work, but it's massively more complicated than most folks realize. I can't make any promises about future function or timelines, but we understand how important secure access is, and are working on it.

Ferguson wrote: »

I'm not cabbey, but no, not by your subdomain's name. You could use https://nickname.smugmug.com internally to link to it and it would work fine but if you use your domain it will trigger a "your connection is not private" or similar error because the name and the cert will not match.

Just enter it in the browser bar and you'll see. Depending on how you use it internally you may or may not see the same error (e.g. how it is embedded), but it will not work correctly.

Since MomaZunk has a custom domain setup, using the nickname with https will cause a 302 to the custom domain, which is not secure. You have to pretend you are sharing a hide owner gallery and use https and photos.smugmug.com to make this work today.

MomaZunk

OK got it.

Just another point about https:, while not a heavily weighted SEO signal at this point, it will become more important to Google. I hope Smugmug gets this going soon.

I know the https conversion is a big undertaking for my site with all of the redirects needed, as I understand its needs to remain in a one to one basis in order to not lose page rank. I cannot imagine the complexity for SMUGMUG.

Ferguson

MomaZunk wrote: »

Just another point about https:, while not a heavily weighted SEO signal at this point, it will become more important to Google. I hope Smugmug gets this going soon.

As part question to Smugmug and caution...

I don't think Smugmug has committed to actually doing this (SSL for custom domains). Is there an intent to do so?

AbigayleRayPhotography

I'll add in my dealings with the https/SSL mess with SmugMug here and it kind of will answer Ferguson's post above (which by the way I see we are basically neighbors, lol small world).

I have been dealing with this issue for a while, to the point that I have a duplicate site at Squarespace (main site is there and sub-domain is with SM), which if not known actually since December 2016 Squarespace has SSL certificates for all custom URL's, so in that respect I am sorry, but if a big company such as Squarespace could figure out how accomplish this, then SmugMug should be able to as well.

There is a workaround using Cloudflare as your CDN to enable https/SSL on a SmugMug site but it has some issues that cause it to not be practical at this time, and in fact during one conversation with a SM Hero was advised not to use it. I have spoke at length with SM support on this and they so state that having https/SSL for custom domain sites is being worked on and is a priority, but if you have been around SM as long as I have, them saying it is a priority and being worked on could mean implementation in a month, or a year, or longer. In fact I had a lengthy email conversation with Aaron who is the head of product at SmugMug and he confirmed the team is working on it but that there are issues with their CDN for implementation, but that they are working on it to make it happen as soon as possible.

And yes, MomaZunk, you are correct where Google (and others) are starting to weight https sites more heavily than http sites which means that this becomes a page rank issue at some point and this is one reason my main site is located elsewhere for now, once SmugMug has it then I will move back over as there are several things I do not like at Squarespace (It is a great site builder/host, but not so much for photographers).

ETA: I just noticed that this thread is just over a year old, apologies for resurrecting an old one, but in the same respect, it shows how long this issue has been going on and yet still nothing has been done about it.