[XSO-624] TLS connection/cert for https://www.xenserver.org fails, issued wrongly for *.cloudaccess.net. Created: 2016-10-04  Updated: 2017-03-17  Resolved: 2017-03-10

Status: Done
Project: XenServer Org
Component/s: other
Affects Version/s: 7.1
Fix Version/s: 7.1

Type: Bug Priority: Major
Reporter: Martin Dehnel-Wild Assignee: Andy Melmed
Resolution: Done Votes: 0
Labels: website
Remaining Estimate: 0 minutes
Time Spent: 1 week
Original Estimate: Not Specified
Environment:

Website


Attachments: PNG File Screenshot 2016-10-04 11.59.54(2).png     PNG File Screen Shot 2016-10-04 at 11.22.00.png     PNG File Screen Shot 2016-10-04 at 11.26.04.png    
Team: xs-pm

 Description   

The TLS / SSL cert for the website fails, as it has been issued for *.cloudaccess.net, and not for xenserver.org, when accessing https://xenserver.org or https://www.xenserver.org

If you click through and accept the certificate anyway, you get an error from it sending you to the wrong server. This is really bad for being the official website for a major hypervisor, as it means we have no way of knowing whether we've downloaded an authentic and unmodified copy of the software.

The site that links to the ISO should have TLS as otherwise it could be MitM'd to point to another ISO. Secondly, the download link to the ISO (http://downloadns.citrix.com.edgesuite.net/11616/XenServer-7.0.0-main.iso) rejects TLS connections, as the certificate is for Akamai, not for the very misleading URL downloadns.citrix.com.edgesuite.net. There is no indication in my mind that edgesuite.net is even a legitimate website, as there's nothing there at the domain/URL apart from an error!

It's really easy to get a valid, free certificate from somewhere such as Let's Encrypt ( https://letsencrypt.org/ ).

I think it is really important that all connections to this site use a valid TLS certificate, and use TLS 1.2 by default.



 Comments   
Comment by Andy Clarkson [ 2016-10-04 ]

We are looking into this.

Comment by Andy Melmed [ 2017-03-10 ]

A SSL certificate has been purchased, validated (by Comodo) and installed on XenServer.org.

The host provider (Cloud Access) confirmed that their hosting environment supports TLS v1.1 and v1.2.

In addition, the site's global configuration has been modified such that all incoming connections to http://xenserver.org are now redirected to https://xenserver.org.

With the above changes in place, the issues for which this ticket was opened have been resolved.

This ticket can be closed.

Comment by Andy Melmed [ 2017-03-10 ]

A SSL certificate has been purchased, validated (by Comodo) and installed on XenServer.org.
The host provider (Cloud Access) confirmed that their hosting environment supports TLS v1.1 and v1.2.
In addition, the site's global configuration has been modified such that all incoming connections to http://xenserver.org are now redirected to https://xenserver.org.
With the above changes in place, the issues for which this ticket was opened have been resolved.
Closing this ticket.

Comment by Martin Dehnel-Wild [ 2017-03-10 ]

P.S. You're still getting mixed content warnings due to images not being loaded from the HTTPS connection!

Comment by Andy Melmed [ 2017-03-10 ]

Thanks Martin.

Are you referring to the images (i.e., Twitter Feeds) on the main page?

Andy

Comment by Martin Dehnel-Wild [ 2017-03-11 ]

Hi Andy,

It's because of things like the following:

		<article>
		
				<a class="image" href="http://twitter.com/tkreidl">
			<img src="http://pbs.twimg.com/profile_images/737053947987263488/Q7sbHZu1_normal.jpg" width="48" height="48" alt="Tobias Kreidl"/>
		</a>
			
		<p class="content"><a href="http://twitter.com/XenJCC">@XenJCC</a> <a href="http://twitter.com/P2Vme">@P2Vme</a> Yes indeed, and as of immediately, the corresponding <a href="http://twitter.com/xenserver">@xenserver</a> 7.1 drivers are now available for do… <a href="https://t.co/XPLi81y7HB">https://t.co/XPLi81y7HB</a></p>
	
				<p class="meta">

						<span class="author">by <a href="http://twitter.com/tkreidl">Tobias Kreidl</a></span>
						
						<a class="statuslink" href="http://twitter.com/tkreidl/statuses/840375859554861056">
				<time datetime="2017-03-10T20:36:33-05:00" pubdate></time>
			</a>
						
		</p>
		
	</article>

You should easily be able to remove all non-HTTPS embedded content, as without it Chrome/Firefox will never show a nice green padlock on the website, but instead a mixed-content warning. If you just make sure all embedded content (Twitter really shouldn't be an issue for this!) is only served over HTTPS it will fix this error. Just doing a quick grep on the source of the https://www.xenserver.org/ homepage shows 78 references to http:// – not all of them will cause this error, but anything embedding content in the page will.

Thanks

Otherwise, you're getting an A on the SSL Labs test for the certificate and config, so full marks there!

Comment by Andy Clarkson [ 2017-03-11 ]

The JIRA tomcat settings need updating to fully support the https reverse proxy. This will require a restart if JIRA.

We are planning to upgrade this JIRA instance to the latest version within the next week so will sort out the reverse proxy settings at the same time.

Comment by Andy Clarkson [ 2017-03-11 ]

I have checked bugs.xenserver.org and it uses a different certificate that is valid, it is only www.xenserver.org that has a problem.

Comment by Andy Melmed [ 2017-03-17 ]

All, I have made the necessary modifications to the /media/widgetkit/widgets/twitter/twitter.php configuration file to ensure all images are loaded securely and confirmed everything is working correctly via https://www.whynopadlock.com.

Thank you for bringing this to my attention.

Andy

Comment by Martin Dehnel-Wild [ 2017-03-17 ]

Wonderful, thank you!

Generated at Thu Jan 17 18:21:59 PST 2019 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.