Certifiaten traag in Citrix XenApp

[winux]

Wij zijn bezig om onze Citrix omgeving in te stellen zodat deze gebruik kan maken van certificaten voor het o.a. ondertekenen van e-mail. Wanneer we dit uitvoeren lopen we tegen het probleem aan dat bij het selecteren van de certificaten binnen Outlook deze enorm lang er over doet voordat we een certificaat kunnen selecteren.

Wanneer we dit echter op dezelfde server onder dezelfde gebruiker, niet via Citrix maar RDP doen, loopt dit wel normaal qua snelheid.

Ook wanneer we de digitale certificaten proberen te openen via SafeSign software geeft deze performance problemen.

Even voor duidelijkheid, we gebruiken de certificaten niet om in te loggen, de gebruikers loggen gewoon in met gebruikersnaam en wachtwoord. Pas daarna gaan we met de certificaten aan de slag.

We maken gebruik van virtuele Windows 2008 R2 servers met daarop Citrix XenApp 7.6. Als Outlook versie maken we gebruik van 2007 (deze wordt binnenkort vervangen door nieuwere versie).

- Op internet kom ik verhalen tegen dat er performance problemen zijn wanneer de server geen CRL kan benaderen en daarom traag wordt. Op de server heb ik gecontroleerd of de proxy server een probleem geeft, maar dit blijkt niet het geval te zijn. Tevens de proxy server uitgeschakeld voor deze sessie.
- Andere certificaten geprobeerd om uit te sluiten dat het probleem in het certificaat zit.
- Andere versies van SafeSign software getest. Ook dit geeft geen probleem.

Verder gekeken bij Citrix of ik daar een knowledge base artikel kan vinden. Maar ik kom daar geen vergelijkbare situaties tegen.

Hopelijk is een van jullie een vergelijkbare situatie tegen gekomen, en kan mij de oplossing of goede richting aandragen.

[Don van Boven]

Welke Citrix client wordt er gebruikt? En toevallig nog andere versies geprobeerd?

[Bor]

Draait er nog iets anders dan alleen Xenapp zoals bv RES Workspace Manager? Heb je getest met exact dezelfde rechten en policies (let ook op de Citrix policies)? Zie je iets in het eventlog? Mijn eerste gok zou ook een timeout zijn bij het ophalen van een CRL moet ik zeggen.

[KnoxNL]

Bor schreef op vrijdag 1 september 2017 @ 15:27:
Draait er nog iets anders dan alleen Xenapp zoals bv RES Workspace Manager? Heb je getest met exact dezelfde rechten en policies (let ook op de Citrix policies)? Zie je iets in het eventlog? Mijn eerste gok zou ook een timeout zijn bij het ophalen van een CRL moet ik zeggen.

Traagheid kan goed veroorzaakt worden door RES of appsense.
Vaak worden die schillen ook niet geladen als je via rdp inlogt.

Indien je appsense gebruikt kun je e.e.a. testen door registry/file virtualization uit te schakelen:

https://community.ivanti.com/docs/DOC-44306

In RES kan dit meen ik door RES geen wijzigingen van de applicatie te laten bijhouden.

[_Arthur]

Puur om er achter te komen of het echt CRL checking is, kan je deze -TIJDELIJK- disabelen dmv policies.

[Question Mark]

_Arthur schreef op vrijdag 1 september 2017 @ 15:32:
Puur om er achter te komen of het echt CRL checking is, kan je deze -TIJDELIJK- disabelen dmv policies.

Of test even of de crl te benaderen is vanuit een browser. Dat test veel sneller...

[winux]

Er draait behalve Citrix policies niets bij. Ben er wel achter gekomen dat het probleem voor 99% zeker veroorzaakt wordt door SafeSign.

Wanneer deze namelijk niet geïnstalleerd is kunnen we "gewoon" gebruik maken van de opties binnen Outlook om certificaten te laden.

Probleem is echter dat de private key op een USB stick staat. En deze dus gebruikt moet maken van SafeSign om te kunnen ondertekenen.

Heb al contact op genomen met onze SafeSign partner. Deze geeft aan dat het zou moeten werken in combinatie met Citrix. Maar wanneer ik de releasenotes lees, staat er wel dat SafeSign alleen met Type 1 hypervisors werkt. Ik twijfel alleen of in onze setup we praten over type 1 of type 2. Aangezien we Citrix XenApp op een gevirtualiseerde omgeving draaien.

[johnkeates]

Als het over het netwerk gaat zou je met wireshark kunnen kijken of er misschien verkeer in een richting gaat, maar niet terug komt, bijvoorbeeld door verkeerde configuratie. Dan zou de client daar een timeout op kunnen hebben met als fallback door gaan om dat een resource niet beschikbaar is (in plaats van hard falen). Kan CRL of OCSP zijn, maar kan op dit moment net zo goed een of andere UI fout zijn.

[3DDude]

winux schreef op zaterdag 2 september 2017 @ 14:44:
Er draait behalve Citrix policies niets bij. Ben er wel achter gekomen dat het probleem voor 99% zeker veroorzaakt wordt door SafeSign.

Wanneer deze namelijk niet geïnstalleerd is kunnen we "gewoon" gebruik maken van de opties binnen Outlook om certificaten te laden.

Probleem is echter dat de private key op een USB stick staat. En deze dus gebruikt moet maken van SafeSign om te kunnen ondertekenen.

Heb al contact op genomen met onze SafeSign partner. Deze geeft aan dat het zou moeten werken in combinatie met Citrix. Maar wanneer ik de releasenotes lees, staat er wel dat SafeSign alleen met Type 1 hypervisors werkt. Ik twijfel alleen of in onze setup we praten over type 1 of type 2. Aangezien we Citrix XenApp op een gevirtualiseerde omgeving draaien.

Type 1: Wordt doorgaans bij bedrijven gebruikt, denk aan VMWare vsphere, Citrix XenServer, Microsoft Hyper-V
Type2: is als jij al een OS hebt, en dan met VMWare workstation, virtualbox enz gaat virtualiseren..

Het is een USB ding die Safesign? en heb je op je Citrix Sessie wel USB redirection dan?
Het lijkt er nu gewoon op dat hij die USBstick niet kan vinden in je Citrix Sessie.

[phantom09]

Kun je de certificaten niet gewoon importeren op de machine zelf in trusted root CA bij local machine?

Of zijn dit user certificates om gebruikers te extern te laten inloggen?
Worden hier toevallig UZi passen gebruikt? Als je de nieuwste safesign software voor gebruikt zou het geen probleem moeten zijn.

[ Voor 53% gewijzigd door phantom09 op 24-09-2017 20:31 ]