USTORE TSL version setup

[michael engstrom]

Hi there,

Hoping to get some advice on this.

Chrome & Firefox have started complaining our SSL certificate uses weak encryption specifically the TSL version.

We have the wildcard SSL in in use on another server/hosting environment and subdomain with no issues.

Where do these need to be set in IIS?

We have a Webproxy & App server setup for our uStore which we host onsite.

Cheers.

[BrianS]

Sounds like you're talking about TLS and SSL?

Google and other major browsers announced in October that they would start marking websites that support deprecated versions of TLS and SSL as "not secure". It sounds like that's what you're describing.

https://blog.chromium.org/2019/10/chrome-ui-for-deprecating-legacy-tls.html?m=1

If no changes are made to your XMpie server connections to your uStore may be refused starting with Chrome version 81, which will be released March 17th 2020.

https://www.chromium.org/developers/calendar

You can test your website using the SSL labs tool from Qualys.
https://www.ssllabs.com/ssltest/

I like using the best practices found in IIS crypto to configure the server to use up-to-date protocols and encryption.
https://www.nartac.com/Products/IISCrypto

Make sure you check your internal systems that may access XMPie via API. That's my Hangup right now.

[michael engstrom]

Hi Brian,

this is exactly the issue I'm trying to solve.

I've had our IT guys looking at it but as they aren't really xmpie support they are a bit lost as to where this needs to be set.

We are just a bit lost as to where this needs to be set? On the Webproxy, or the app server or both.

[couch]

It is not unique or specific to XMPie. Any web server will encounter the same issue with older SSL certificates.

Therefore, since XMPie uses MS IIS, any Microsoft IT support specialist should be able to help you obtain and install a new certificate.

As far as the "which server" question, if you have a web proxy server and a separate uStore server, then the certificate needs to be on both servers since the proxy is just redirecting the https request to the uStore server.

[michael engstrom]

I'm not sure it's our certificate though as it's a wildcard certificate and we have it installed on another hosting platform that isn't giving the same warnings.

[Wayne]

Hi Michael,

I would assume your Servers are not PCI Compliant.

If not I would recommend you check out the PCI Compliance website https://www.pcisecuritystandards.org/  and use this as a guide on how you should setup your servers.

Regards,

Wayne

[couch]

I'd recommend you to log a support case with your Xerox/Fuji Xerox/XMPie support team because you probably shouldn't have a public discussion with details of your infrastructure.

[michael engstrom]

cheers

will do.

[Brian Shipe]

This is NOT a problem with your SSL certificate.

Run your site through the SSL labs test website, you'll see that.

The problem is with the TLS & SSL protocols supported (or not) and the Ciphers on the server.

Like couch mentioned, this is not an XMpie (software) issue. Any company hosting web sites will need to keep their webservers up to date.

Use that SSL labs URL I sent earlier and plug in your uStore URL. You'll get a report of the Security of the website. This report will give plenty of actionable information and Terms to Google if the IT staff isn't sure what to do.

Like this:

This server supports SSL 2, which is obsolete and insecure, and can be used against TLS (DROWN attack). Grade set to F.   MORE INFO »

This server uses SSL 3, which is obsolete and insecure. Grade capped to B. MORE INFO »

The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.  MORE INFO »

This server accepts RC4 cipher, but only with older protocols. Grade capped to B.  MORE INFO »

This server does not support Forward Secrecy with the reference browsers. Grade capped to B.  MORE INFO »

This server does not support Authenticated encryption (AEAD) cipher suites. Grade capped to B.  MORE INFO »

This server supports TLS 1.0. Grade capped to B.

The nartac.com link I sent has software to download that makes updating the server (if the windows OS supports it) a snap.

Your IT folks need to understand what to do, how to fix it and how that impacts your other systems.

--
You received this message because you are subscribed to a topic in the Google Groups "XMPie Interest Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xmpie-users/NYQXs5LZJls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xmpie-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xmpie-users/147c9d8b-6b77-4512-bce8-ad19c3f3ecfd%40googlegroups.com.

[Wizard2013TriggerService]

Hi Michael,

Is not a matter of the certificate, SSL certificates are all SHA256. The problem here is at the server level, and the solution is simple. Just enable TSL 1.2 in the Registry (SCHANNEL Key), this will be sufficient for Chrome and Firefox. To be PCI 100%, you will need to tweak the Ciphers and other stuff.

Instead of getting inside the registry, you may use the Nartac IIS solution IISCrypto https://www.nartac.com/ (just in case backup first you registry using export inside regedit).

Regards

Aritz

[markb]

Hi all, we updated our Base and Proxy uStore server over the weekend using IISCrypto's default PCI 3.2.1 template and we passed PCI scan attestation ok, however then our XMPL hosted projects on the Proxy server stopped working. The error was POST https://ourdomain.com/XMPieXMPL_REST_API..... (Internal Server Error 500, Login failed with input data). The input data looks to be an access token associated with a xmp js file used for the XMPL client side integration. Does this mean we should plan to host our XMPL projects on a different server other than our proxy server (which has our managed sites from Circle) or do we ONLY need to update security settings on our Base server? Just wondering if anyone has worked through PCI compliance for uStore and also hosting XMPL pages that need to communicate to Circle. Thanks Mark

[markb]

FYI, my hunch is after reviewing server error event logs, is that Circle requires a specific protocol that we turned off for PCI compliance - I won't mention which one for security. We're going update to the latest versions of uStore, uProduce and Circle hopefully by April and see if the latest versions give us a different result with the PCI compliant settings we need to change for uStore. We may need to plan to separate managed site hosting so it's separate from our uStore proxy perhaps.