Cliente@firma

El cliente de firma es una aplicación cliente de Firma Electrónica que se ejecuta en el PC del usuario. Está basado en Applets Java, por lo que es necesario tener instalada la máquina virtual de Java, que será el entorno donde se ejecutará dicha aplicación

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

Si el seu certificat resideix en una targeta intel·ligent (DNIe) o tokenUSB, aquests 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 signatura.

El cliente de firma es un Applet Java. Este tipo de aplicación tiene la peculiaridad que se ejecuta siempre en el ordenador del usuario; para ejecutarlo, el navegador debe soportar JAVA (se trata de una tecnología para aplicaciones software independiente de la plataforma) utilizando lo que se llama el Entorno de Ejecución de Java (JRE) que será donde se ejecute el cliente de firma.

Perquè un Applet Java pugui accedir als recursos protegits del PC de l'usuari, com llegir fitxers localment o realitzar la signatura electrònica, aquest ha d'anar signat digitalment per la companyia que ho ha desenvolupat, i només si l'usuari confia en aquesta companyia (en utilitzar un applet signat, 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 cliente de firma está firmado con un certificado del Ministerio de la Presidencia. Los detalles del certificado se muestran a continuación:

ASSUMPTE:
• SERIALNUMBER=S2811001C,
• CN=Signa Codi. Mpr. D.G. Impuls De l'Administracion Electronica,
• OU=D.G. Per 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 Signatura 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 instalada en el navegador (sólo en navegadores compatibles con Java 5). La compatibilidad con Java 5 es una funcionalidad a extinguir, se recomienda actualizar a Java 6
• JRE 6 ó JRE 7 instalado en el navegador (1.6 update 30 o 7 update 2 recomendadas)
 

El client permet crear signatures digitals en diferents formats (per defecte CAdES). Globalment se suporten els següents formats i normatives de signatura 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 “Adobi PDF”.
• ODF (Open Document Format): Representat per la cadena “ODF”.
• OOXML (Office Open XML): Representat per la cadena “OOXML”.

El formato se puede cambiar con el método setSignatureFormat que recibe como parámetro la cadena que representa al formato en cuestión.

Las variantes EPES de los formatos de firma que las soportan se generarán automáticamente al configurar el formato de firma correspondiente y una política de firma (para más información se recomienda consultar la documentación del Cliente de Firma).
 

La clase “clienteFirma” tiene el método “setShowHashMessage” que recibe como parámetro un valor booleano (true o false) que indica si se mostrará o no dicha ventana.

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. Aquests arxius són els ".ZIP" i els plug-ins del Client de Signatura. 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. Aquests arxius són els ".JAR" i el fitxer "version.properties".

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

En ocasions, les finestres del client perden el focus, fent impossible lainteracción de l'usuari. Aquest 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 aquest error se soluciona en canviar el focus a altres finestres, o minimitzar/maximitzar el navegador, per intentar que recuperi 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'estableixin diverses sessions de forma simultània, i si per qualsevol raó (sessió SSL, etc.) el propi navegador Web Mozilla / Firefox té ja establerta una comunicació amb el DNIe al moment en el qual el Client @signa també ho necessita, aquest últim es queda bloquejat esperant al fet que en navegador Mozilla /Firefox tanqui la seva sessió. El tancament de la sessió contra el DNIe per part de Mozilla / Firefox pot trigar diversos minuts si l'usuari no intervé, per la qual cosa convé forçar manualment aquest tancament:
• Extreure el DNIe del lector i tornar-ho a inserir just al 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 reobri la sessió en la reinserció (avançant-se al Client @signa), per la qual cosa potser necessiti repetir l'operació.
• Podem indicar a Mozilla / Firefox que tanqui la sessió prement el botó “Registre out” tenint el dispositiu “DNIe PKCS#11 Moduli” seleccionat en la finestra “Dispositius de Seguretat” del menú Opcions de Mozilla Firefox. Igual que en el mètode anterior, de vegades és necessari repetir l'operació diverses vegades, ja que Mozilla / Firefox reobre automàticament la comunicació amb el DNIe sense donar temps al Client @signa a utilitzar-ho. En altres ocasions, el botó apareix deshabilitat encara que Mozilla / Firefox tingui una sessió oberta contra el dispositiu, amb el que no és possible aplicar aquest mètode.

Este problema se da predominantemente en Linux, Solaris y Mac OS X. No se ha detectado en ningún caso en ninguna versión 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 aquestes plataformes indicant que mai s'ha de bloquejar l'accés a les targetes intel·ligents.

Per realitzar aquesta 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 moduli 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 usi it, until
# the first is doni 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 usi several smart card aware
# applications at the same estafi, i.g. you cannot run both
# Firefox and Thunderbird at the same estafi, if both llauri
# configured to usi your smart card.
#
# Default: true
lock_login = false;

Atès que aquest canvi pot tenir 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), realitzi únicament aquestes modificacions si està completament segur de les seves 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 cliente actualiza los API Apache Xalan y Apache Xerces de Java 5 por las últimas versiones disponibles a fecha de publicación de este. Estas versiones son completamente compatibles con las anteriores incluidas con Java 5, por lo que no introducen ningún problema de compatibilidad.

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

Durante la creación de un String de Java a partir de un binario obtenido a su vez de la decodificación de un Base64 se pueden pervertir los caracteres especiales de los ficheros XML si se indica una codificación errónea en el constructor de la clase String. La solución más rápida es no indicar codificación y confiar en las capacidades de Java de auto-detección de formato de caracteres. Si esta auto-detección de Java sigue proporcionando resultados incorrectos siempre puede obtener los XML directamente como texto en vez de en Base64 usando el método getSignatureText() en vez de getSignatureBase64Encoded().

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

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

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

A veces puede ocurrir que el navegador no detecta la extracción o introducción del DNIe (u otra tarjeta inteligente) en el lector, por lo que si no hemos introducido la tarjeta previamente a que se arranque el cliente de firma, no se encontrará el certificado. Otro posible caso es que una vez cargado el cliente, se extraiga la tarjeta y, al realizar una operación de firma, el navegador muestre los certificados de la tarjeta (aunque ya no esté presente) fallando al intentar utilizarlo.

Este es un problema del navegador en la gestión de los dispositivos criptográficos (PKCS#11 para Mozilla y CSP para Internet Explorer), que no informa a la sesión abierta en el almacén de certificados de los cambios que se producen en el mismo.

La solución más rápida al problema es el insertar la tarjeta antes de que se produzca la carga del cliente de firma.

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

En cas que necessiti inter-operar el Client @signa amb l'aplicació de Finestreta Única de la Seguretat Social, per favor, obri una incidència contra aquesta última.

Consulte las sección 13.1 del manual del integrador para más información sobre el despliegue del Cliente de Firma en servidores Web que requieren identificación de los usuarios mediante certificado cliente.

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 actualitzi el seu entorn d'execució de Java (JRE) a una versió més moderna.

El Client no signa les fulles d'estil dels fitxers XML: La versió actual del Client de Signatura sí permet signes 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 signatura.

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

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

El Client no genera signatures XML usant empremtes digitals SHA-2: El error de Java 6845600 (http://bugs.sun.com/view_bug.do?bug_id=6845600) afecta a la generación de firmas XML con SHA-256 y SHA-512. Para sortear estos problemas debe usar Java 6u30 o Java 7u2..
 

El Client produeix un error de derreferenciación en generar signes XAdES: javax.xml.crypto.URIReferenceException: Errors en les primeres versions de Java 7 produeixen problemes interns de derreferenciación en generar signatures XAdEScuandose configura la propietat “contentTypeOid”. Aquests errors de Java queden solucionats en Java 7 o4. Actualitzi a aquesta versió de java 7 o superior per solucionar el problema.
 

El Client no permet la signatura de PDF amb certs certificats

Las firmas de documentos PDF realizadas externamente (que es el método utilizado por el Cliente) tienen un tamaño máximo de octetos que pueden ocupar dentro del PDF.

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

Al cargar el Cliente @firma aparece el componente instalador solicitando la introducción de la contraseña de usuario privilegiado, pero o no deseo introducirla por motivos de seguridad o aunque la introduzca el proceso termina en error.

Per a l'ús del repositori de Mozilla Firefox en Mac US X és necessari que les biblioteques NSS estiguin 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 aquest a la llista de rutes de càrrega de biblioteques.
Per sortejar aquesta dificultat, el Client @signa, mitjançant el seu component instal·lador (BootLoader), intenta crear enllaços simbòlics d'aquestes biblioteques des del directori de Firefox a /usr/lib, carpeta dins de la llista de directoris de càrrega de biblioteques. Per realitzar aquesta còpia, es necessiten certs privilegis, i és per aquesta raó per la qual se sol·licita la contrasenya d'usuari privilegiat.

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

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

Mozilla Firefox 11 introdueix canvis a les seves biblioteques d'accés al magatzem de certificats. Aquests canvis poden afectar al Client @signa impedint-li accedir al seu magatzem en sistemes en els quals no és possible carregar aquestes biblioteques.
 

Existeixen 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, provi a agregar el directori de biblioteques de Firefox en el PATH del sistema (consulti les instruccions del seu sistema operatiu concret).
 

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

En versions antigues d'Internet Explorer no és possible tenir simultàniament obertes dues o més pàgines que continguin diferents instàncies del Client @signa

És possible que en versions 7 i anteriors d'Internet Explorer obrir una segona pàgina que contingui el Client @signa tenint una altra ja oberta ocasioni fallades de càrrega en la segona o un malfuncionamiento general en ambdues.
Actualitzi 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 sortejar aquests problemes. Si per qualsevol motiu no pot actualitzar Internet Explorer provi a usar un altre navegador Web, com Google Chrome.

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

La arquitectura IA64 en Windows no está soportada por el Cliente y no lo estará en un futuro próximo.

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…) interfereixen en el funcionament de les biblioteques SunMSCAPI de Java per a l'ús dels certificats del sistema operatiu. Aquesta 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ó estigui també executant-se, generi un error intern en la màquina virtual de Java que tanca instantàniament l'aplicació afectada.
 

Este es un problema generado por aplicaciones nativas Windows que acceden a CAPI por medios no recomendados y por defectos de la biblioteca SunMSCAPI, encargada del acceso al almacén de certificados de Windows, que no puede ser tratado, que impiden operar cuando se realizan estos accesos no recomendados.
 

En general, ha d'intentar evitar-se la situació on una aplicació utilitzi una targeta intel·ligent alhora que s'usa el client de signatura. Per fer-ho, convé separar l'ús de les dues aplicacions que accedeixen 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 arribés a produir-se aquest error, és possible que necessiti tancar l'aplicació Windows que produeix la incompatibilitat i reiniciar l'aplicació (pàgina Web) que integra el client @signa.

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 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 @signa no podrà accedir al magatzem de Firefox si no compta amb aquest 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/segurs de creació de signatures per obrir sobres digitals

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

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

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

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

Compruebe si las páginas HTML que desea firmar cumplen estrictamente con el formato XHTML (que sí es compatible XML) y si no seleccione otro formato de firmas.

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

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

Algunos dispositivos de creación de firma no funcionan con las funcionalidades de firma multi-fase del Cliente.

Estas limitaciones son impuestas por los fabricantes de los dispositivos de creación de firmas y no es posible sortearlas. Consulte con el fabricante de su dispositivo de creación de firmas para comprobar que funcionalidades pueden estar restringidas.

La configuración de filtros de certificados produce un error cuando se establece un filtro de gran tamaño.

Aquest 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'aquest tipus es produeix 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'aquest 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 adreça estàtica dins del servidor Web, com per exemple: http://adreça/directori_classes
• El JavaScript (las bibliotecas JS) debe incluirse dentro de la página que invoca al Applet y puede generarse dinámicamente, pero debe editarse el fichero constantes.js para indicar su localización mediante una URL absoluta:

/*******************************************************************************
* Ruta als instal·lables. *
* Si no se establece, supone que estan en el mismo directorio (que el HTML). *
******************************************************************************/
var baseDownloadURL = http://direccion/directori_classes;

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

El Client d'@signatura, en la seva primera execució, copia certs fitxers al disc dur de l'usuari per garantir una correcta execució. Aquests fitxers són en gran majoria biblioteques binàries nadives, encara que si l'usuari utilitza l'entorn d'execució de Java en la seva 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 fer ús des de Java 5 de les funcionalitats incorporades en les versions actuals de Java. Aquest paquet és obligatori quan s'executa el client des d'aquesta 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 Directorio de bibliotecas del sistema (por ejemplo, /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.
Dado que los directorios sujetos a necesidades de permisos son usados únicamente si el usuario utiliza la versión 5 del entorno de ejecución de Java, existen dos posibilidades para resolver los posibles fallos de instalación:
1. Actualització a Java 6 (solució recomanada).
2. Canvi dels permisos d'usuari dels directoris afectats.
a. Consulte el manual de usuario de su sistema operativo para los procedimientos de cambio de permisos en directorios.
3. Instal·lació manual de les biblioteques.
a. Ha de descomprimir els fitxers comprimits ZIP (consulti el manual del seu sistema operatiu per als procediments de descompressió de fitxers ZIP) a les carpetes apropiades.
b. Després de la descompressió deu igualment ajustar els permisos dels directoris i les biblioteques descomprimides:
i. Los directorios deben tener permisos de lectura, no es necesario permisos de escritura.
ii. Las bibliotecas necesitan permisos de lectura y ejecución, no es necesario permisos de escritura.