Cliente@firma

El client de firma és una aplicació client de Firma Electrònica que s'executa en el PC de l'usuari. Està basat en Applets Java, per la qual cosa és necessari tindre instal·lada la màquina virtual de Java, que serà l'entorn on s'executarà aquesta aplicació

Bàsicament, el client rep dades i els retorna firmats, utilitzant per a açò els certificats instal·lats en el magatzem de certificats (keystore) del navegador on s'estiga executant en eixe moment. La raó per la qual s'executa en el client és perquè la codificació de la firma electrònica s'efectua en l'ordinador de l'usuari, utilitzant la clau privada del certificat seleccionat, que residix en el seu PC.

Si el seu certificat residix en una targeta intel·ligent (DNIe) o tokenUSB, estos són carregats automàticament en el magatzem de certificats a través dels controladors (drivers) dels dispositius, per la qual cosa seran accessibles des del client de firma.

El client de firma és un Applet Java. Este tipus d'aplicació té la peculiaritat que s'executa sempre en l'ordinador de l'usuari; per a executar-ho, el navegador ha de suportar JAVA (es tracta d'una tecnologia per a aplicacions programari independent de la plataforma) utilitzant el que es diu l'Entorn d'Execució de Java (JRE) que serà on s'execute el client de firma.

Perquè un Applet Java puga accedir als recursos protegits del PC de l'usuari, com llegir fitxers localment o realitzar la firma electrònica, este ha d'anar firmat digitalment per la companyia que ho ha desenvolupat, i només si l'usuari confia en eixa companyia (en utilitzar un applet firmat, l'usuari ha d'acceptar una finestra d'advertiment de seguretat en la qual se li indica qui és el propietari de l'aplicació) el client s'executarà.

El client de firma està firmat amb un certificat del Ministeri de la Presidència. Els detalls del certificat es mostren a continuació:

ASSUMPTE:
• SERIALNUMBER=S2811001C,
• CN=Firma Codi. Mpr. D.G. Impuls De l'Administracion Electronica,
• OU=D.G. Per a l'Impluso De l'Administracion Electronica,
• O=Ministeri De la Presidència,
• L=Madrid,
• ST=Madrid,
• C=ÉS

EMISSOR:
• CN=AC Camerfirma Codesign v2,
• O=AC Camerfirma SA,
• OU=http://www.camerfirma.com,
• SERIALNUMBER=A82743287,
• L=Madrid (see current address at www.camerfirma.com/address),
• EMAILADDRESS=info@camerfirma.com,
• C=ÉS

Els requisits mínims d'ús del Client de Firma són els següents:

Els navegadors suportats fins al moment són:

• Firefox 3.0 i superiors.
• Internet Explorer 7 o superior, en 32 i 64 bits.
• Google Chrome 4 o superior.
• Apple Safari 4 o superior.
• Opera 10 o superior.

Els sistemes operatius suportats són:
• Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 i superiors
• Linux 2.6 (Guadalinex i Ubuntu) i superiors.
• Mac US X 10.6.8 i 10.7.2 (Snow Leopard i Lion).

JRE:
• JRE 5 (1.5 update 22) o superior instal·lada en el navegador (només en navegadors compatibles amb Java 5). La compatibilitat amb Java 5 és una funcionalitat a extingir, es recomana actualitzar a Java 6
• JRE 6 ó JRE 7 instalado en el navegador (1.6 update 30 o 7 update 2 recomendadas)
 

El client permet crear firmes digitals en diferents formats (per defecte CAdES). Globalment se suporten els següents formats i normatives de firma electrònica:

• CMS: Representat per la cadena “CMS/PKCS#7”.
• CAdES: Representat per la cadena “CAdES”.
• XMLDSig Internally Detached: Representat per la cadena “XMLDSig Detached”.
• XMLDSig Enveloping: Representat per la cadena “XMLDSig Enveloping”.
• XMLDSig Enveloped: Representat per la cadena “XMLDSig Enveloped”.
• XAdES Internally Detached: Representat per la cadena “XAdES Detached”.
• XAdES Enveloping: Representat per la cadena “XAdES Enveloping”.
• XAdES Enveloped: Representat per la cadena “XAdES Enveloped”.
• PAdES: Representat per la cadena “Adobe PDF”.
• ODF (Open Document Format): Representat per la cadena “ODF”.
• OOXML (Office Open XML): Representat per la cadena “OOXML”.

El format es pot canviar amb el mètode setSignatureFormat que rep com a paràmetre la cadena que representa al format en qüestió.

Les variants EPES dels formats de firma que les suporten es generaran automàticament en configurar el format de firma corresponent i una política de firma (para més informació es recomana consultar la documentació del Client de Firma).
 

La classe “clienteFirma” té el mètode “setShowHashMessage” que rep com a paràmetre un valor booleà (true o false) que indica si es mostrarà o no aquesta finestra.

La variable "baseDownloadURL" especifica la ubicació on es troben els arxius d'instal·lació, en cas de no es trobar-se en el mateix directori que l'HTML. Estos arxius són els ".ZIP" i els plug-ins del Client de Firma. La variable "base" especifica la ubicació on es troben els arxius de l'instal·lador, en cas de no es trobar-se en el mateix directori que l'HTML. Estos arxius són els ".JAR" i el fitxer "version.properties".

El Client de Firma funciona en local, i per tant, no realitza connexió amb cap Plataforma de Firma i/o segellat de temps, per la qual cosa no és possible generar firmes amb segell de temps. Una possibilitat és utilitzar d'obtindre aquestes firmes és utilitzar el servici d'Upgrade de firma de la Plataforma @firma, amb el qual és possible afegir un segell de temps a les firmes generades amb el Client de Firma, així, una Firma XAdES s'actualitzaria a XAdES-T.

En ocasions, les finestres del client perden el focus, fent impossible lainteracción de l'usuari. Este error es deu a un error reconegut per SunMicrosystems a partir del JRE 1.5.0 que bloqueja certes finestres Java en Internet Explorer i Mozilla, perdent el focus i fent impossible la interacció amb l'usuari.

En molts casos este error se soluciona en canviar el focus a altres finestres, o minimitzar/maximitzar el navegador, per a intentar que recupere el focus, encara que no sempre resulta efectiu, per la qual cosa s'haurà de reiniciar el navegador i reintentar l'operació. En cas de problemes greus amb alguna aplicació Web concreta, és recomanable l'ús d'Internet Explorer, on el problema apareix en menor mesura.

El controlador PKCS#11 del DNIe no admet que s'establisquen diverses sessions de forma simultània, i si per qualsevol raó (sessió SSL, etc.) el propi navegador Web Mozilla / Firefox té ja establida una comunicació amb el DNIe en el moment en el qual el Client @firma també ho necessita, este últim es queda bloquejat esperant al fet que en navegador Mozilla /Firefox tanque la seua sessió. El tancament de la sessió contra el DNIe per part de Mozilla / Firefox pot tardar diversos minuts si l'usuari no interven, per la qual cosa convé forçar manualment este tancament:
• Extraure el DNIe del lector i tornar-ho a inserir just en el moment en el qual se sol·licita la contrasenya del Repositori Central de certificats de Mozilla Firefox (abans d'introduir-la). És possible que Mozilla / Firefox reòbriga la sessió en la reinserció (avançant-se al Client @firma), per la qual cosa potser necessite repetir l'operació.
• Podem indicar a Mozilla / Firefox que tanque la sessió polsant el botó “Registre out” tenint el dispositiu “DNIe PKCS#11 Module” seleccionat en la finestra “Dispositius de Seguretat” del menú Opcions de Mozilla Firefox. Igual que en el mètode anterior, a voltes és necessari repetir l'operació diverses vegades, ja que Mozilla / Firefox reobri automàticament la comunicació amb el DNIe sense donar temps al Client @firma a utilitzar-ho. En altres ocasions, el botó apareix deshabilitat encara que Mozilla / Firefox tinga una sessió oberta contra el dispositiu, amb el que no és possible aplicar este mètode.

Este problema es dona predominantment en Linux, Solaris i Mac US X. No s'ha detectat en cap cas en cap versió de Windows.

Una solució alternativa en sistemes basats en UNIX (Linux, Solaris, Mac OSX) és modificar la configuració d'OpenSC (producte en el qual es basa el controlador PKCS#11 del DNIe en estes plataformes indicant que mai s'ha de bloquejar l'accés a les targetes intel·ligents.

Per a realitzar esta indicació ha de modificar l'arxiu de configuració d'OpenSC, normalment situat en /etc/opensc/opensc.conf i assegurar-se que conté una línia descomentada amb l'opció lock_login=false; :
# By default, the OpenSC PKCS#11 module will lock your card
# onze you authenticate to the card via C_Login.
# This is to prevent other users or other applications
# from connecting to the card and perform crypto operations
# (which may be possible because you have already authenticated
# with the card). Thus this setting is very secure.
#
# This behavior is a known violation of PKCS#11 specification,
# and is forced due to limitation of the OpenSC framework.
#
# However now onze one application has started using your
# card with C_Login, no other application ca use it, until
# the first is done and calls C_Logout or C_Finalize.
# In the case of many PKCS#11 application this does not happen
# until you exit the application.
#
# Thus it is impossible to use several smart card aware
# applications at the same estafe, i.g. you cannot run both
# Firefox and Thunderbird at the same estafe, if both llaure
# configured to use your smart card.
#
# Default: true
lock_login = false;

Atés que este canvi pot tindre implicacions de seguretat amb altres targetes intel·ligents (la seguretat del DNIe no es veu compromesa per ell, atés que implementa mesures addicionals de protecció, com la implementació de la normativa CWA-14890), realitze únicament estes modificacions si està completament segur de les seues implicacions.

En certes distribucions de Linux (com Guadalinex v6) el canvi no tenen cap efecte sobre els bloquejos amb DNIe, per la qual cosa no solucionarà el problema).

El client actualitza els API Apatxe Xalan i Apatxe Xerces de Java 5 per les últimes versions disponibles a data de publicació d'est. Estes versions són completament compatibles amb les anteriors incloses amb Java 5, per la qual cosa no introduïxen cap problema de compatibilitat.

Addicionalment, si es detecta la versió 5 de JRE s'instal·la el proveïdor de seguretat SunMSCAPI en la seua versió 6, ja que Java 5 originalment no ho inclou. Esta instal·lació no canvia ni actualitza cap funcionalitat, sinó que afig possibilitats completament noves, per la qual cosa no és possible que supose problema de compatibilitat algun.

Durant la creació d'un Cadena de Java a partir d'un binari obtingut al seu torn de la descodificació d'un Base64 es poden pervertir els caràcters especials dels fitxers XML si s'indica una codificació errònia en el constructor de la classe Cadena. La solució més ràpida és no indicar codificació i confiar en les capacitats de Java d'acte-detecció de format de caràcters. Si esta acte-detecció de Java seguix proporcionant resultats incorrectes sempre pot obtindre els XML directament com a text en comptes d'en Base64 usant el mètode getSignatureText() en comptes de getSignatureBase64Encoded().

Quan s'introduïx malament el PIN del DNIe, ocorre que el navegador no detecta els seus certificats, fins i tot encara que posteriorment l'usuari sí ho introduïsca correctament.

El problema vé del CSP (Cryptographic Service Provider) del DNI electrònic i la millor forma de solucionar-ho és extraure i inserir el DNIe en el lector de targeta i tornar-se a autenticar.

En el cas de Mozilla Firefox, és possible que haja de tancar i tornar a obrir el navegador per a reiniciar la sessió del client i es detecten els certificats.

A voltes pot ocórrer que el navegador no detecta l'extracció o introducció del DNIe (o una altra targeta intel·ligent) en el lector, per la qual cosa si no hem introduït la targeta prèviament al fet que s'arranque el client de firma, no es trobarà el certificat. Un altre possible cas és que una vegada carregat el client, s'extraga la targeta i, en realitzar una operació de firma, el navegador mostre els certificats de la targeta (encara que ja no estiga present) fallant en intentar utilitzar-ho.

Est és un problema del navegador en la gestió dels dispositius criptogràfics (PKCS#11 per a Mozilla i CSP per a Internet Explorer), que no informa a la sessió oberta en el magatzem de certificats dels canvis que es produïxen en el mateix.

La solució més ràpida al problema és l'inserir la targeta abans que es produïsca la càrrega del client de firma.

Este aplicatiu de Finestreta Única de la Seguretat Social modifica parts del JRE reemplaçant biblioteques vitals per al Client @firma per versions ja obsoletes.

En cas que necessite inter-operar el Client @firma amb l'aplicació de Finestreta Única de la Seguretat Social, per favor, òbriga una incidència contra esta última.

Consulte les secció 13.1 del manual de l'integrador para més informació sobre el desplegament del Client de Firma en servidors Web que requerixen identificació dels usuaris mitjançant certificat client.

El client necessita, dins de la branca Java 5, almenys la versió 1.5o18 (es recomana encaridament l'actualització a Java 6o18 o almenys Java 5o22). Si està usant versions de Java anteriors a 1.5o18 actualitze el seu entorn d'execució de Java (JRE) a una versió més moderna.

El Client no firma les fulles d'estil dels fitxers XML: La versió actual del Client de Firma sí permet firmes fulles d'estil, atés que les fulles d'estil d'un XML poden declarar-se de diferents formes, el client adopta diferents estratègies per a cada forma de declaració i segons la variant de firma.

Les firmes XMLDSig generades no són compatibles amb SOAP: Esta funcionalitat està en estudi per a ser inclosa en futures versions del Client.

Certs validadors no accepten algunes de les firmes generades pel Client @firma: Revise amb detall la matriu de compatibilitat i les “NOTES IMPORTANTS” del manual del Format XML.

El Client no genera firmes XML usant empremtes digitals SHA-2: L'error de Java 6845600 (http://bugs.sun.com/view_bug.do?bug_id=6845600) afecta a la generació de firmes XML amb SHA-256 i SHA-512. Per a sortejar estos problemes ha d'usar Java 6o30 o Java 7o2..
 

El Client produïx un error de derreferenciación en generar firmes XAdES: javax.xml.crypto.URIReferenceException: Errors en les primeres versions de Java 7 produïxen problemes interns de derreferenciación en generar firmes XAdEScuandose configura la propietat “contentTypeOid”. Estos errors de Java queden solucionats en Java 7 o4. Actualitze a esta versió de java 7 o superior per a solucionar el problema.
 

El Client no permet la firma de PDF amb certs certificats

Les firmes de documents PDF realitzades externament (que és el mètode utilitzat pel Client) tenen una grandària màxima d'octets que poden ocupar dins del PDF.

Com la firma inclou la cadena de certificació completa, si esta és molt extensa pot arribar a esgotar-se este espai i resultar en una firma invàlida o corrupta. Si açò li ocorre, per favor, pose's en contacte amb el servici d'atenció als usuaris del Client @firma enviant una còpia del seu certificat de firma i la cadena de confiança completa. Tinga sempre molta cura de no enviar mai les parts privades dels certificats.

En carregar el Client @firma apareix el component instal·lador sol·licitant la introducció de la contrasenya d'usuari privilegiat, però o no desitge introduir-la per motius de seguretat o encara que la introduïsca el procés acaba en error.

Per a l'ús del repositori de Mozilla Firefox en Mac US X és necessari que les biblioteques NSS estiguen situades dins d'una ruta de càrrega de biblioteques, però Firefox en instal·lar-se en Mac US X les instal·la en el seu propi directori, sense afegir este a la llista de rutes de càrrega de biblioteques.
Per a sortejar esta dificultat, el Client @firma, mitjançant el seu component instal·lador (BootLoader), intenta crear enllaços simbòlics d'estes biblioteques des del directori de Firefox a /usr/lib, carpeta dins de la llista de directoris de càrrega de biblioteques. Per a realitzar esta còpia, es necessiten certs privilegis, i és per esta raó per la qual se sol·licita la contrasenya d'usuari privilegiat.

Per a més informació consulte el Manual d'Integrador i la Guia d'incidències del Client de Firma.
 

No és possible accedir al magatzem de Mozilla Firefox 11 i superiors

Mozilla Firefox 11 introduïx canvis en les seues biblioteques d'accés al magatzem de certificats. Estos canvis poden afectar al Client @firma impedint-li accedir al seu magatzem en sistemes en els quals no és possible carregar estes biblioteques.
 

Existixen múltiples motius pel que poden no carregar-se les biblioteques de forma correcta. Si no pot accedir al magatzem de certificats de Mozilla Firefox, prove a agregar el directori de biblioteques de Firefox en el PATH del sistema (consulte les instruccions del seu sistema operatiu concret).
 

Tinga en consideració:
• Ha d'agregar la ruta del directori principal de Firefox.
• Si compta amb diverses versions de Firefox assegure's d'indicar la ruta de la versió amb la qual vaja a utilitzar el Client @firma i no agregue més d'una.
• L'arquitectura del navegador ha de ser la mateixa que la de Java. Preferiblement, utilitze versions de Mozilla Firefox i Java de 32 bits.
 

En versions antigues d'Internet Explorer no és possible tindre simultàniament obertes dos o més pàgines que continguen diferents instàncies del Client @firma

És possible que en versions 7 i anteriors d'Internet Explorer obrir una segona pàgina que continga el Client @firma tenint una altra ja oberta ocasione fallades de càrrega en la segona o un malfuncionamiento general en les dos.
Actualitze a l'última versió d'Internet Explorer disponible per al seu sistema operatiu Windows i a almenys la versió 6o30 de l'entorn d'execució de Java (JRE) per a sortejar estos problemes. Si per qualsevol motiu no pot actualitzar Internet Explorer prove a usar un altre navegador Web, com Google Chrome.

El Client no Funciona Correctament en Windows sobre arquitectura IA64 (Intel Itanium)

L'arquitectura IA64 en Windows no està suportada pel Client i no ho estarà en un futur pròxim.

El Client deixa de funcionar per complet quan estic utilitzant-ho alhora que una aplicació nativa Windows que fa ús d'una targeta intel·ligent

Algunes aplicacions natives de Windows que fan ús de targetes intel·ligents com el DNIe (aplicació d'escriptori, controls ActiveX en pàgines Web d'Internet Explorer…) interferixen en el funcionament de les biblioteques SunMSCAPI de Java per a l'ús dels certificats del sistema operatiu. Esta interferència provoca que qualsevol intent d'una aplicació Java d'accedir al magatzem de certificats de Windows quan es té inserida la targeta intel·ligent en el lector mentre l'altra aplicació estiga també executant-se, genere un error intern en la màquina virtual de Java que tanca instantàniament l'aplicació afectada.
 

Est és un problema generat per aplicacions natives Windows que accedixen a CAPI per mitjans no recomanats i per defectes de la biblioteca SunMSCAPI, encarregada de l'accés al magatzem de certificats de Windows, que no pot ser tractat, que impedixen operar quan es realitzen estos accessos no recomanats.
 

En general, ha d'intentar evitar-se la situació on una aplicació utilitze una targeta intel·ligent alhora que s'usa el client de firma. Per a fer-ho, convé separar l'ús de les dos aplicacions que accedixen a la targeta mitjançant l'extracció i reinserció de la mateixa en el lector o simplement tancant la resta de les aplicacions mentre s'usa una d'elles.
 

Si arribara a produir-se este error, és possible que necessite tancar l'aplicació Windows que produïx la incompatibilitat i reiniciar l'aplicació (pàgina Web) que integra el client @firma.

No és possible accedir al magatzem de Firefox en sistemes Windows amb Java 6o32 o superior i Java 7o4 o superior

La JRE d'Oracle per a Windows utilitza a partir de les versions o32 de Java 6 i o4 de Java 7 l'entorn d'execució de Visual C++ 2010. El Client @firma no podrà accedir al magatzem de Firefox si no compta amb este entorn d'execució instal·lat en el seu sistema. Pot descarregar-ho des de:
http://www.microsoft.com/download/en/details.aspx?id=5555
 

El client no permet usar el DNIe ni altres dispositius segurs de creació de firmes per a obrir sobres digitals

Certs emissors de certificats residents en dispositius segurs de creació de firma limiten en origen l'ús que se'ls pot donar a estos.

En el cas del DNIe (i altres dispositius), no es permet el seu ús per a obrir sobres digitals per no estar eixe ús autoritzat per l'emissor. Deu sempre evitar enviar sobres digitals a particulars si no està segur que els seus certificats (en la seua part privada) van a permetre posteriorment la seua obertura.

No és possible firmar una pàgina Web amb el format XMLDSig/XAdES Enveloped

XAdES/XMLDSig Enveloped solament admet firmar fitxers XML, i no totes les pàgines HTML són compatibles XML.

Comprove si les pàgines HTML que desitja firmar complixen estrictament amb el format XHTML (que sí és compatible XML) i si no seleccione un altre format de firmes.

Algun dels formats de firma generats amb el Client @firma no validen adequadament en altres plataformes.

Comprove sempre les matrius de compatibilitat del client per a verificar que els formats no estan subjectes a problemes d'adequació amb normatives/estàndards (quan açò ocórrega estarà així indicat) i quins dels quals no presenten estos problemes estan suportats per la seua plataforma validadora.

Alguns dispositius de creació de firma no funcionen amb les funcionalitats de firma multi-fase del Client.

Estes limitacions són imposades pels fabricants dels dispositius de creació de firmes i no és possible sortejar-les. Consulte amb el fabricant del seu dispositiu de creació de firmes per a comprovar que funcionalitats poden estar restringides.

La configuració de filtres de certificats produïx un error quan s'establix un filtre de gran grandària.

Este error ocorre en usar un filtre de certificats mitjançant el mètode deprecado “setCertFilter(Cadena)” o “setMandatoryCertificateCondition(Cadena)”.
En concatenar/niar múltiples expressions d'este tipus es produïx un error en la JVM que obliga a desactivar el filtre. Ha d'evitar-se l'ús de filtres amb múltiples expressions.
És recomanable migrar les aplicacions al nou sistema de filtres basat en la RFC 2254. Poden establir-se filtres d'este tipus mitjançant el mètode “setCertFilterRFC2254(Cadena, Cadena, boolean)”.
 

Quan es desplega el Client en entorns on les pàgines HTML es generen dinàmicament no és possible carregar l'Applet

Les pàgines HTML proveïdes com a exemple necessiten certs canvis quan es vol desplegar el Client en servidors on les pàgines es generen dinàmicament (com per exemple, Portlets en un Servidor de Portals):
• Les biblioteques Java del client (JAR) han de situar-se en una direcció estàtica dins del servidor Web, com per exemple: http://direcció/directori_classes
• El Javascript (les biblioteques JS) ha d'incloure's dins de la pàgina que invoca a l'Applet i pot generar-se dinàmicament, però ha d'editar-se el fitxer constantes.js per a indicar la seua localització mitjançant una URL absoluta:

/*******************************************************************************
* Ruta als instalables. *
* Si no s'establix, suposa que estan en el mateix directori (que l'HTML). *
******************************************************************************/
var baseDownloadURL = http://direccion/directori_classes;

/*******************************************************************************
* Ruta a l'instal·lador. *
* Si no s'establix, suposa que estan en el mateix directori (que l'HTML). *
******************************************************************************/
var base = http://direccion/directori_classes;

El Client d'@firma, en la seua primera execució, copia certs fitxers al disc dur de l'usuari per a garantir una correcta execució. Estos fitxers són en gran majoria biblioteques binàries natiu, encara que si l'usuari utilitza l'entorn d'execució de Java en la seua versió 5 també s'actualitzen certes classes Java d'est. Concretament, la llista de fitxers instal·lats és la següent:

• Java 5 i superiors
Atos Origin Windows Short Path Name Utility (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Mozilla / Firefox. Es troba en el fitxer comprimit ShortPathName.zip. Directori d'instal·lació: $HOME/afirma.5/aoutil/
- ShortPathName.dll
Java Deploy Utility Library for Windows (solament s'instal·la en sistemes Windows). Es troba en el fitxer comprimit deploy.zip. Directori d'instal·lació: $HOME/afirma.5/aoutil/
- aodeploy.dll

• Únicament Java 5 (no es necessiten en versions superiors)
Paquet de compatibilitat del client amb Java 5 (Linux/Windows). Necessari per a fer ús des de Java 5 de les funcionalitats incorporades en les versions actuals de Java. Este paquet és obligatori quan s'executa el client des d'esta versió de Java. Directori d'instal·lació: $JAVA_HOME/lib/endorsed
- afirma_5_java_5.jar
JavaMS-CAPI Native Library (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer. Es troba en el fitxer comprimit capi.zip. Directori d'instal·lació: $JAVA_HOME/bin/
- sunmscapi.dll
Entorn d'execució de Microsoft Visual C++ 7.1 (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer, és una dependència derivada de la biblioteca anterior. Es troba en el fitxer comprimit msvcr71.zip. Directori d'instal·lació: $LIBRARY_PATH/
- msvcr71.dll
Java MS-CAPI Provider (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer. Es troba en el fitxer comprimit mscapiJar.zip. Directori d'instal·lació: $JAVA_HOME/lib/ext/
- sunmscapi.jar
En els directoris d'instal·lació, les següents cadenes representen a directoris del sistema operatiu dependents de la instal·lació:
1. $HOME Directorio de usuario (por ejemplo, /export/home/user en un sistema Linux o C:\Documents and Settings\user en un sistema Windows)
2. $JAVA_HOME Directori d'instal·lació de l'entorn d'execució de Java
3. $LIBRARY_PATH Directori de biblioteques del sistema (per exemple, /lib en un sistema Linux o C:\Windows\SYSTEM32 en un sistema MS-Windows 32 Bits)
Dels tres directoris, el primer no presenta necessitats especials respecte a permisos, ja que l'usuari sempre té els apropiats sobre ell, però els altres dos poden estar restringits a operacions de lectura, execució o escriptura, la qual cosa pot provocar una instal·lació fallida.
Atés que els directoris subjectes a necessitats de permisos són usats únicament si l'usuari utilitza la versió 5 de l'entorn d'execució de Java, existixen dos possibilitats per a resoldre les possibles fallades d'instal·lació:
1. Actualització a Java 6 (solució recomanada).
2. Canvi dels permisos d'usuari dels directoris afectats.
a. Consulte el manual d'usuari del seu sistema operatiu per als procediments de canvi de permisos en directoris.
3. Instal·lació manual de les biblioteques.
a. Ha de descomprimir els fitxers comprimits ZIP (consulte el manual del seu sistema operatiu per als procediments de descompressió de fitxers ZIP) en les carpetes apropiades.
b. Després de la descompressió deu igualment ajustar els permisos dels directoris i les biblioteques descomprimides:
i. Els directoris han de tindre permisos de lectura, no és necessari permisos d'escriptura.
ii. Les biblioteques necessiten permisos de lectura i execució, no és necessari permisos d'escriptura.