Jump to content


Photo

SSL error 61: you have not chosen to trust

Started by Ict Department , 06 October 2008 - 11:47 AM
10 replies to this topic

Ict Department Members

Ict Department
  • 16 posts

Posted 06 October 2008 - 11:47 AM

Hello all,

Our situation: CAG 4.2.3 AAC + WI Citrix 4.0
Some of our users ( Apple MAC) are getting a certificate error when connecting to a published app.
We have uploaded the certificate to the CAG this works fine with windows client.

Any idea where this issue could come from ?

Thanks !
Elwood

Attached Files



KEN ZYGMUNT Members

KEN ZYGMUNT
  • 1,284 posts

Posted 06 October 2008 - 10:58 PM

Are you using the Java ICA Client, or have you installed the full Citrix client for the MAC?



Ict Department Members

Ict Department
  • 16 posts

Posted 09 October 2008 - 09:33 AM

We are using the latest MAC client, but with JAVA we get a similar message.



Henny Louwers Members

Henny Louwers
  • 121 posts

Posted 09 October 2008 - 09:52 AM

What kind of certificate have you purchased? Brand? type?

Maybe you have to install the (Intermediate) SSL Root Certificate on the Mac Clients locally. (Read: Manually).

You are running a somewhat older version of the Citrix Accessa Gateway AAC, I would recommend to update to at least 4.5 which resolves a lot of issues.



Sathiyamoorthi Thangasamy Members

Sathiyamoorthi Thangasamy
  • 63 posts

Posted 09 October 2008 - 10:23 AM

I am also facing the same error in my CAG 4.5 with Windows XP.

Attached Files



Henny Louwers Members

Henny Louwers
  • 121 posts

Posted 09 October 2008 - 11:07 AM

In your image (however) it states that the client has a problem trusting the 'certsrv' certificate. Is this, I'm guessing, a private certificate? Then you will have to distribute the root certificate to your (Windows XP) clients.

If not, then you will have to provide more information about your setup.

Although I do think this is a entirely different problem.



Alessandro Paiusco Members

Alessandro Paiusco
  • 48 posts

Posted 15 October 2008 - 02:21 PM

I had a similar error with ica client for linux, and I had to copy ca root file (a crt file) in /usr/lib/ICAClient/keystore/cacerts,
I think it's the same problem for Ica client for MAC, you have to copy the ca root in the ica clients' cacerts directory on Mac.



Eckhard Eilers Members

Eckhard Eilers
  • 16 posts

Posted 21 October 2008 - 07:18 PM

Folks,

same problem here. This is, what I found out by now:

the Citrix ICA Client Version 10 seems to take the Certs from the system keystore, so just doubclick the cert and choose the keystore (login / system / system-root) you want to save the cert in.
Then: You will have to open the keystore (sorry, but I don't have the english application name here, should be something like "Keychain Access" or so.
Here You can set the certificate as "trusted". Just doubleclick the cert an choose "Trust" (I Think it is named the way, I only have ther german version :-( just use the first twisty) and set it to "trust always".
this SHOULD work. (It does not at my site, but I will keep on trying).

Update: Don't Know what it finally was, but: I created a folder in /applications/Citrix ICA Client named "keystore". In this folder I created a folder called "cacerts". I copied the root certs (crt-files) to this folder. full path is:

/Applications/Citrix ICA Client/keystore/cacerts/.

Now it works :-)

cheers

EKKI

Edited by: Eckhard Eilers on 21.10.2008 21:21



Ict Department Members

Ict Department
  • 16 posts

Posted 22 October 2008 - 09:15 AM

@Henny Louwers

Let me give you a bit of history on how we got into this problem.
We used to have a certificate of Verisign. The mac clients were able to connect to Citrix without any problems. When that certificate was about to expire we made the decision to go for a certificate of Digicert.
Digicert required an intermediate certificate to be installed on the Citrix backend, and so we did.
Regrettably that immediately gave a similar error as first reported. The Citrix java client gave the following error:

SSL Error 0: You have not chosen to trust
"Entrust.net Secure Server Certification Authority",
the issuer of the server's security certificate.

After that we decided to then go for a Verisign certificate again.
Regrettably new Verisign certificates now seem to require an intermediate certifcate also.
We have installed that intermediate certificate on the Citrix backend.
The Citrix java client gave the error we reported:

SSl Error 61: You have not chosen to trust
"VeriSign Class 3 Secure Server CA, The issuer of
the server's security certifcate.

We have recently upgraded to the latest version 4.5.1 and still the same error occurs.

I appreciate the solutions offered to solve this problem on the client site, but it will we undoable and unacceptable for us to start changing setting on the (mac) clients.
We expect the Citrix vpn solution to function properly in all cases, also when using it in internet cafe's, without requiring to manually import any intermediate certificates on the client site.
We know that this should be possible, because our webmail solution also uses an intermediate certificate and mac clients have no problem what so ever to use their webmail.

My question therefore is simple:

I am under the impression that the Citrix java client is unable to handle intermediate certificates properly, resulting in the errors mentioned.

Is the Citrix VPN java client currently compatible with intermediate certificates, yes or no?

Edited by: ICT Afdeling on Oct 22, 2008 11:20 AM

Edited by: ICT Afdeling on Oct 22, 2008 11:23 AM



James Crocker Citrix Employees
  • #10

James Crocker
  • 1,624 posts

Posted 22 October 2008 - 12:30 PM

My question therefore is simple:

I am under the impression that the Citrix java client is unable to handle intermediate certificates properly, resulting in the errors mentioned.

Is the Citrix VPN java client currently compatible with intermediate certificates, yes or no?

Both the java client, and the VPN client are fine with intermediate certificates. The issue here is with trusts of certificates, and this is something outside of the Citrix components and relies on the client system instead. Both the Java ICA client and the VPN client will ask the system it is running on whether the system trusts the server certificate presented by the CAG. For the Java client, this means asking the JRE. For the VPN client this means asking Windows.

When the system checks, one of the steps it does is to see who signed the certificate, and match that against its list of trusted signers. If it knows it, great, that test has been passed. if it doesnt know it, then this si flagged as an issue. For the VPN client, the user is told that the signer is untrusted, and has the option of continuing. For the Java ICA client, this options is not available.

This applies in exactly the same way with intermediate certificates too. When the system checks the server certificate and finds it was signed vy "verisign intermediate" it also checks to see who that certificate was signed by... Thus you have a path of Intermediate certificates. This hierarchy can continue for multiple levels.

Having explained how this all works, I'll explain how to help your environment.

Part of the SSL standard allows the SSL server to send the Intermediate CA hierarchy along with the actual server certificate up to the root CA as a part of the SSL handshake. So for example, in your scenario the CAG can be configured to send the SSL cert of the CAG AND the Verisign Intermediate certificate. The client is still responsible for trusting the Root cert though.

So the system receives the server cert and sees it is signed by the intermediate certificate. Before it even looks into its own system keystore it will see that the intermediate certificate that signed the server certificate has also been sent, and it will then look to see if it trusts the signer of the Intermediate. With Verisign, that is almost always the case since most OS keystores will include the Verisign root cert.

As to how to achieve this - when you upload the certificate to the CAG, you have to upload a PEM file that contains both the server certificate and the intermediate certificate in the same file. The problem is that unless you generated your private key and the csr outside of the CAG, then you cannot upload a certificate a second time, since the private key already has a certificate bound to it.

You can either create a new CSR on the CAG, or create a CSR for signing using a tool such as OpenSSL. Verisign (or other public CA's) should allow a certificate to be reissued using the new CSR.

Appendix B of the CAG admin guide discusses how to then create the PEM file for upload that includes the Intermediate Certificate. The Admin Guide can be found here: http://support.citri...ticle/ctx118140

http://support.citrix.com/article/ctx111872 might also be of interest.



Henny Louwers Members
  • #11

Henny Louwers
  • 121 posts

Posted 22 October 2008 - 12:38 PM

This article also might be of interest:
http://support.citrix.com/article/CTX112336

I've had before that I had to combine the Certificates and upload them then to the Citrix Access Gateway.

Look at Resolution 2:

The CA sends you the server certificate through email (plain text) or as a file attachment (most likely a *.crt file) and possibly the intermediate certificate as well.

To support intermediate certificates with the Access Gateway, using a text editor, append the intermediate certificate to the end of the server certificate and save it as one *.crt file - be sure not to add any additional line breaks (see below):

-----BEGIN CERTIFICATE-----
MIIEmzCCBASgAwIBAgIQUA+CBRtJXo7NNMSTaf20RTANBgkqhkiG9w0BAQUFADCBujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy9YStMo5mCIfVpoOuxeLMZMK8CAJopblanLXGWvj7WaoTVNRtzPSYBqe8Qg0+WZSozYBWbjlWugtn0bAt5PECAwEAAaOCAYUwggGBMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL0NsYXNzM0ludGVybmF0aW9uYWxTZXJ2ZXIuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHSUELTArBglghkgBhvhCBAEGCisGAQQBgjcKAw345CsGAQUFBwMBBggrbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLd6pZjANBgkqhkiG9w0BAQUFAAOBgQCUDHDOPU6Kmk9/tRsBt7k5QzKDq0MRY/bhWuNi5tO8WkYtoX8MSCmyay+hs49ezFTezdSJ0KsguGaoE+VFdAJMf0Sg+wRQKce0p4sVM4hYv6AKaq8RCEig4R9YSNV3LFAlJe5LJwYU9CadK74biIjW771kJuUYHhFTM6G9VKJrmA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDgzCCAuygAwIBAgIQJUuKhThCzONY+MXdriJupDANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT4zCB4DAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQEwKjAoBggrBgEFBQcCRXYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIEAQYKYIZIAYb4RQEIATALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3MA5n0GCSqGSIb3DQEBBQUAA4GBAAgB7ORolANC8XPxI6I63unx2sZUxCM+hurPajozq+qcBBQHNgYL+Yhv1RPuKSvD5HKNRO3RrCAJLeH24RkFOLA9D59/+J4C3IYChmFOJl9en5IeDCSk9dBwE88mw0M9SR2egi5SX7w+xmYpAY5Okiy8RnUDgqxz6dl+C2fvVFIa
-----END CERTIFICATE-----