gmtx
Hot Shot
Hot Shot

Teradici 4.0 firmware and SAN certs

Jump to solution

Been using a SAN cert on my conneciton servers that has about a dozen SAN entries with no problems on zero clients with 3.51 firmware, but after upgrading one of the clients to 4.0 firmware I now get a warning that the cert is not trusted, and I see the following in the zero client logs:

05/20/2012, 09:12:19> LVL:3 RC:   0        MGMT_SYS :(ui_cback): event: 43
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:-505       X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full
05/20/2012, 09:12:19> LVL:1 RC:xFFFFE8E6   MGMT_SSL :ocsp_http_query: remapping error to ERR_OCSP_RESPONDER_CONNECT_FAILED
05/20/2012,  09:12:19> LVL:1 RC:xFFFFC552   MGMT_SSL  :mgmt_ssl_certificate_revocation_test:  mgmt_ssl_ocsp_validate_certificate() failed: Unknown Err
05/20/2012,  09:12:19> LVL:2 RC:-500     MGMT_VDMCSI :Warn on View Default mode:  VCS certificate meets WoVD no trusted root exception

I have a ticket open with Teradici (for nine days) and still no response from them, other than a ticket status of "Work in Progress". Anyone else seeing any issues with 4.0 firmware and certs with multiple SAN entries?

Thanks,


Geoff

0 Kudos
1 Solution

Accepted Solutions
pharmer
Enthusiast
Enthusiast

Had the same issue with our Digicert wildcard

I uploaded the intermediate cert as a .pem only via a new profile and psuhed that out to some test P20's - all good

The Digicert was called Digicert High Assurance CA-3

cert.JPG

cert2.JPG

View solution in original post

0 Kudos
37 Replies
pharmer
Enthusiast
Enthusiast

Same issue here testing the Teradici V4 firmware on Wyse P20's

SSL certs are trusted wildcard or multi SAN - they all work fine with the View 5.1 connection servers and the Windows/Mac View clients

Only the P20 with new firmware has an issue

I too have now opened a job with Teradici

0 Kudos
williamsfudge
Enthusiast
Enthusiast

Have also opened a case with Teradici.  Strange how they weren't ready for all these 5.1 changes.  I wonder if VMware released 5.1 ahead of schedule?

VCP on vSphere 4
0 Kudos
gmtx
Hot Shot
Hot Shot

Well, after nearly two weeks I finally got a response from Teradici, basically saying that I hadn't uploaded a proper root cert to my zero client. Oh my. Guess reading case notes and debug logs is a lost art.

I responded asking them to look closely at the error messages - sure looks to me like they haven't allocated enough space for multiple SAN entries - and I again pointed them to a URL for one of my security servers so they can test this for themselves. I hope their troubleshooting skills are better this time around and that it doesn't take another two weeks to hear back.

This is my first Teradici support experience, and so far it's pretty disappointing.

Geoff

0 Kudos
lmhealthcare
Contributor
Contributor

Here is a good question. How do you upload a proper root cert to the thin client?

I'm getting the same errors, and I use a GoDaddy SAN cert. On the off chance that they were correct I thought i'd put up the godaddy intermediate and root. No joy. The profile won't apply with the certs in it, and the certs won't apply directly either.

0 Kudos
kmiatke
Contributor
Contributor

Same problem here.  Teradici said just upload the root.  Using an Entrust cert with two SAN names an intermediate and root chain.  I'd say this is an issue.

0 Kudos
pharmer
Enthusiast
Enthusiast

Had the same issue with our Digicert wildcard

I uploaded the intermediate cert as a .pem only via a new profile and psuhed that out to some test P20's - all good

The Digicert was called Digicert High Assurance CA-3

cert.JPG

cert2.JPG

0 Kudos
gmtx
Hot Shot
Hot Shot

OK, I have to take back my snide remarks about not reading the case notes. Uploading the intermediate - and in my case, also the root cert - to the zero client fixed the problem. Thanks pharmer for giving me the motivation to try the solution. I've been working on about 100 other things the last couple of days and frankly, the Teradici response sounded like a canned "move on to the next case", answer. In fact, the answer they gave was correct.

Geoff

0 Kudos
williamsfudge
Enthusiast
Enthusiast

Call me dumb, but how did you get your .crt files from digicert to .pem files?

Thanks,

Phil

VCP on vSphere 4
0 Kudos
gmtx
Hot Shot
Hot Shot

Just rename them. Smiley Happy

Geoff

0 Kudos
williamsfudge
Enthusiast
Enthusiast

Oh well that was easy!

Well they're uploaded. But I'm still getting the invalid cert warning.  I wonder if it is the wildcard cert?   Argh!

VCP on vSphere 4
0 Kudos
gmtx
Hot Shot
Hot Shot

You store on the client looks like this?:

0 Kudos
pharmer
Enthusiast
Enthusiast

I've just got the digicert intermediate installed - thats it

cert3.JPG

On your view connection servers, use the digicert tool to mkae sure all root/intermediate and host certs are installed correctly

cert4.JPG

make sure the ssl cert for your host has the friendly name of vdm

cert7.JPG

Status in View connecton server is good as well

cert6.JPG

0 Kudos
runitsaaron
Enthusiast
Enthusiast

I'm waiting for Unidesk to be compatible before I do my upgrade to View 5.1 and Teradici 4.0, but I have a question about the SSL cert problem everyone seems to be having.  It sounds like this is the same issue that happened when they upgraded the iPad view client a while back and it wouldn't connect due to an SSL cert error.  Does anyone know if that is true?  If so, then I think I won't have any issues with it since I uploaded the root cert to my domain already.  Thanks!

0 Kudos
williamsfudge
Enthusiast
Enthusiast

ARe you using the Digicert SSL certs for your internal connection servers?  I'm using Windows CA for internal connections.

I'm just using my *.domain.com for external security server in my DMZ.  Should I also install the certs on the internal connection server servicing the security server?

Do you change the friendly name to VDM for the security server certificate?

Is anyone having issues with wildcard certs?

VCP on vSphere 4
0 Kudos
gmtx
Hot Shot
Hot Shot

Yes, I'm using DigiCert certs for all my servers, internal and external.

You'll want certs on all your servers (esx, vc, connection servers and security servers) now with 5.1. The vc cert needs an "rui" friendly name (and a fixed password), and the connection server certs need the "vdm" friendly name. esx doesn't care, and I can't remember if security servers need a friendly name, but you can always play it safe and use "vdm".

Not sure about wildcard certs (I'm using a UC cert with over a dozen SAN entries), but I think there are others here who are using wildcards successfully.

Geoff

0 Kudos
kmiatke
Contributor
Contributor

So for my Entrust certificate issue, I was able to resolve it by including a third certificate; the Secure Server CA.

Certificates.jpg

0 Kudos
lmhealthcare
Contributor
Contributor

Teradici just released a KB for updating certificates.

http://techsupport.teradici.com/ics/support/default.asp?deptID=15164

They have not even looked at the ticket I submitted almost a week ago though.

0 Kudos
Stu_Robinson
Enthusiast
Enthusiast

Hi All,

This is Stu from Teradici jumping in.  Bear with me, this is a long response but is intended to help clarify the problems some are experiencing configuring SSL certificates for PCoIP zero client firmware 4.0.0 to connect with VMware View 5.1.

First, my apologies to those that have had a delay in response for your tickets.  As you can see from the posts in this blog, there has been a spike in requests which has impacted our typical response times.  Additional resources have been focused on helping resolve these issues as soon as possible.

Background:

View 5.1 has implemented new security measures including setting SSL as the default for clients connecting to the View Connection Server.  In order to be certified by VMware, clients must perform a VCS certificate check and have the security level set to Warn.  Firmware 4.0.0 supports the new security measures so that it can be certified with View 5.1. 

View 5.0 did not have SSL by default which is why connecting to View  5.0 or earlier with Firmware 3.x.x was fine.  Note if you use FW3.x.x to connect to View 5.1, you will have to enable SSL in the zero clients for the View Connection Server mode.

Why can’t the zero client make a secure connection to VCS 5.1?

PCoIP zero clients are highly secure and they are shipped with an empty trust store – outside of the default PCoIP root CA’s that are used to manage zero clients and when connecting to a PCoIP host card for remote workstations.

PC’s and Thin Clients are different and often contain certificates for common CA’s which can match the trusted root that was installed in the company’s VCS.  Including CA’s automatically increases the surface area for security issues/attacks – Microsoft had some of their certificates hacked and they had to revoke some of their certs this week - http://securitywatch.pcmag.com/microsoft-windows/298622-microsoft-revokes-certificates-used-by-flame....

So for zero clients, CA’s must be explicitly installed by admins.  If the trust store is empty and no certs have been installed, then the zero client will allow users to connect after they click through a warning.

** NOTE **  If you have already installed a certificate (like IEEE 802.1x EAP/TLS network authentication certs) then the connection will be blocked.

To avoid being blocked or have warnings displayed:

  • Upload a trusted root certificate to the zero client (through the web page or the PCoIP Management Console)
  • Or you can set the VCS Certificate Check mode to “Allow the unverifiable connection (Not Secure)” by the zero client web page.  Users can also do this from the connect screen by selecting Options> User Settings and then clicking on Allow.

My team has not had a problem with the certificates we have uploaded to our zero clients.  Also, we have been able to successfully upload certificates to connect to some customer’s VCS as we work through the tickets.

However, we have found some common configuration issues for which we have created knowledge base articles on the Teradici support site to help identify and resolve them - see  http://techsupport.teradici.com/ics/support/default.asp?deptID=15164&task=knowledge&questionID=1063.  Here is a list of common configuration issues:

0d,00:00:18> LVL:1 RC:-505 X509_UTIL :x509_util_subject_alternative_name_cback: SAN buffer is full  -  The SAN buffer full message is not a problem and does not affect the connection to the VCS.   However, we will make a change in a future firmware build to avoid this log message.

05/29/2012, 14:41:37> LVL:1 RC:xFFFFC556 MGMT_SSL :mgmt_ssl_certificate_revocation_test: mgmt_ssl_ocsp_validate_certificate() failed: Unknown Err  -  This message is not a problem as it does not impact the connection to the VCS.

We are actively investigating whether there could be an issue handling some certificates. The Teradici support site will be updated as we get more information (techsupport.teradici.com) and I’ll update this blog too.

For those with tickets open – thanks for your patience, we are working to get to your ticket as soon as possible.

For those having a problem but have not yet opened a ticket, please open one at techsupport.teradici.com.  Again, my team has additional resources focused on resolving these issues as soon as possible.

Thanks,

Stu

Director of Systems Engineering, Teradici

0 Kudos
gmtx
Hot Shot
Hot Shot

Thanks for posting Stu. It's great to hear directly from Teradici on an issue that's become a major headache for everyone involved.

While I agree that making connectivity more secure is a worthwhile goal, the documentation and configuration procedures sure could be more concise and easier to find (especially on the VMware side of things). The phrase "some assembly required" comes to mind. Anyway, good to see you putting up KB articles and comments in this thread, and hopefully this saves others a bit of time and frustration.

Geoff

0 Kudos