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ásicamente, el cliente recibe datos y los devuelve firmados, utilizando para ello los certificados instalados en el almacén de certificados (keystore) del navegador donde se esté ejecutando en ese momento. La razón por la que se ejecuta en el cliente es porque la codificación de la firma electrónica se efectúa en el ordenador del usuario, utilizando la clave privada del certificado seleccionado, que reside en su PC.

Si su certificado reside en una tarjeta inteligente (DNIe) o tokenUSB, estos son cargados automáticamente en el almacén de certificados a través de los controladores (drivers) de los dispositivos, por lo que serán accesibles desde el cliente de firma.

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.

Para que un Applet Java pueda acceder a los recursos protegidos del PC del usuario, como leer ficheros localmente o realizar la firma electrónica, éste debe ir firmado digitalmente por la compañía que lo ha desarrollado, y sólo si el usuario confía en esa compañía (al utilizar un applet firmado, el usuario debe aceptar una ventana de advertencia de seguridad en la que se le indica quien es el propietario de la aplicación) el cliente se ejecutará.

El cliente de firma está firmado con un certificado del Ministerio de la Presidencia. Los detalles del certificado se muestran a continuación:

ASUNTO:
• SERIALNUMBER=S2811001C,
• CN=Firma Código. Mpr. D.G. Impulso De La Administracion Electronica,
• OU=D.G. Para El Impluso De La Administracion Electronica,
• O=Ministerio De La Presidencia,
• L=Madrid,
• ST=Madrid,
• C=ES

EMISOR:
• 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=ES

Los requisitos mínimos de uso del Cliente de Firma son los siguientes:

Los navegadores soportados hasta el momento son:

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

Los sistemas operativos soportados son:
• Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 y superiores
• Linux 2.6 (Guadalinex y Ubuntu) y superiores.
• Mac OS X 10.6.8 y 10.7.2 (Snow Leopard y 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 cliente permite crear firmas digitales en distintos formatos (por defecto CAdES). Globalmente se soportan los siguientes formatos y normativas de firma electrónica:

• CMS: Representado por la cadena “CMS/PKCS#7”.
• CAdES: Representado por la cadena “CAdES”.
• XMLDSig Internally Detached: Representado por la cadena “XMLDSig Detached”.
• XMLDSig Enveloping: Representado por la cadena “XMLDSig Enveloping”.
• XMLDSig Enveloped: Representado por la cadena “XMLDSig Enveloped”.
• XAdES Internally Detached: Representado por la cadena “XAdES Detached”.
• XAdES Enveloping: Representado por la cadena “XAdES Enveloping”.
• XAdES Enveloped: Representado por la cadena “XAdES Enveloped”.
• PAdES: Representado por la cadena “Adobe PDF”.
• ODF (Open Document Format): Representado por la cadena “ODF”.
• OOXML (Office Open XML): Representado por 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ón donde se encuentran los archivos de instalación, en caso de no se encontrarse en el mismo directorio que el HTML. Estos archivos son los ".ZIP" y los plug-ins del Cliente de Firma. La variable "base" especifica la ubicación donde se encuentran los archivos del instalador, en caso de no se encontrarse en el mismo directorio que el HTML. Estos archivos son los ".JAR" y el fichero "version.properties".

El Cliente de Firma funciona en local, y por tanto, no realiza conexión con ninguna Plataforma de Firma y/o sellado de tiempo, por lo que no es posible generar firmas con sello de tiempo. Una posibilidad es utilizar de obtener dichas firmas es utilizar el servicio de Upgrade de firma de la Plataforma @firma, con el cual es posible añadir un sello de tiempo a las firmas generadas con el Cliente de Firma, así, una Firma XAdES se actualizaría a XAdES-T.

En ocasiones, las ventanas del cliente pierden el foco, haciendo imposible lainteracción del usuario. Este error se debe a un error reconocido por SunMicrosystems a partir del JRE 1.5.0 que bloquea ciertas ventanas Java en Internet Explorer y Mozilla, perdiendo el foco y haciendo imposible la interacción con el usuario.

En muchos casos este error se solventa al cambiar el foco a otras ventanas, o minimizar/maximizar el navegador, para intentar que recupere el foco, aunque no siempre resulta efectivo, por lo que se deberá reiniciar el navegador y reintentar la operación. En caso de problemas graves con alguna aplicación Web concreta, es recomendable el uso de Internet Explorer, en donde el problema aparece en menor medida.

El controlador PKCS#11 del DNIe no admite que se establezcan varias sesiones de forma simultánea, y si por cualquier razón (sesión SSL, etc.) el propio navegador Web Mozilla / Firefox tiene ya establecida una comunicación con el DNIe en el momento en el que el Cliente @firma también lo necesita, este último se queda bloqueado esperando a que en navegador Mozilla /Firefox cierre su sesión. El cierre de la sesión contra el DNIe por parte de Mozilla / Firefox puede tardar varios minutos si el usuario no interviene, por lo que conviene forzar manualmente este cierre:
• Extraer el DNIe del lector y volverlo a insertar justo en el momento en el que se solicita la contraseña del Repositorio Central de certificados de Mozilla Firefox (antes de introducirla). Es posible que Mozilla / Firefox reabra la sesión en la reinserción (adelantándose al Cliente @firma), por lo que quizás necesite repetir la operación.
• Podemos indicar a Mozilla / Firefox que cierre la sesión pulsando el botón “Log out” teniendo el dispositivo “DNIe PKCS#11 Module” seleccionado en la ventana “Dispositivos de Seguridad” del menú Opciones de Mozilla Firefox. Al igual que en el método anterior, a veces es necesario repetir la operación varias veces, ya que Mozilla / Firefox reabre automáticamente la comunicación con el DNIe sin dar tiempo al Cliente @firma a utilizarlo. En otras ocasiones, el botón aparece deshabilitado aunque Mozilla / Firefox tenga una sesión abierta contra el dispositivo, con lo que no es posible aplicar este método.

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ón alternativa en sistemas basados en UNIX (Linux, Solaris, Mac OSX) es modificar la configuración de OpenSC (producto en el que se basa el controlador PKCS#11 del DNIe en estas plataformas indicando que nunca se debe bloquear el acceso a las tarjetas inteligentes.

Para realizar esta indicación debe modificar el archivo de configuración de OpenSC, normalmente situado en /etc/opensc/opensc.conf y asegurarse de que contiene una línea descomentada con la opción lock_login=false; :
# By default, the OpenSC PKCS#11 module will lock your card
# once 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 once one application has started using your
# card with C_Login, no other application can 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 time, e.g. you cannot run both
# Firefox and Thunderbird at the same time, if both are
# configured to use your smart card.
#
# Default: true
lock_login = false;

Dado que este cambio puede tener implicaciones de seguridad con otras tarjetas inteligentes (la seguridad del DNIe no se ve comprometida por él, dado que implementa medidas adicionales de protección, como la implementación de la normativa CWA-14890), realice únicamente estas modificaciones si está completamente seguro de sus implicaciones.

En ciertas distribuciones de Linux (como Guadalinex v6) el cambio no tienen ningún efecto sobre los bloqueos con DNIe, por lo que 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.

Adicionalmente, si se detecta la versión 5 de JRE se instala el proveedor de seguridad SunMSCAPI en su versión 6, ya que Java 5 originalmente no lo incluye. Esta instalación no cambia ni actualiza ninguna funcionalidad, sino que añade posibilidades completamente nuevas, por lo que no es posible que suponga problema de compatibilidad alguno.

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().

Cuando se introduce mal el PIN del DNIe, ocurre que el navegador no detecta sus certificados, incluso aunque posteriormente el usuario sí lo introduzca correctamente.

El problema viene del CSP (Cryptographic Service Provider) del DNI electrónico y la mejor forma de solucionarlo es extraer e insertar el DNIe en el lector de tarjeta y volverse a autenticar.

En el caso de Mozilla Firefox, es posible que deba cerrar y volver a abrir el navegador para reiniciar la sesión del cliente y se detecten los certificados.

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.

Este aplicativo de Ventanilla Única de la Seguridad Social modifica partes del JRE reemplazando bibliotecas vitales para el Cliente @firma por versiones ya obsoletas.

En caso de que necesite inter-operar el Cliente @firma con la aplicación de Ventanilla Única de la Seguridad Social, por favor, abra una incidencia contra esta ú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 cliente necesita, dentro de la rama Java 5, al menos la versión 1.5u18 (se recomienda encarecidamente la actualización a Java 6u18 o al menos Java 5u22). Si está usando versiones de Java anteriores a 1.5u18 actualice su entorno de ejecución de Java (JRE) a una versión más moderna.

El Cliente no firma las hojas de estilo de los ficheros XML: La versión actual del Cliente de Firma sí permite firmas hojas de estilo, dado que las hojas de estilo de un XML pueden declararse de distintas formas, el cliente adopta distintas estrategias para cada forma de declaración y según la variante de firma.

Las firmas XMLDSig generadas no son compatibles con SOAP: Esta funcionalidad está en estudio para ser incluida en futuras versiones del Cliente.

Ciertos validadores no aceptan algunas de las firmas generadas por el Cliente @firma: Revise con detalle la matriz de compatibilidad y las “NOTAS IMPORTANTES” del manual del Formato XML.

El Cliente no genera firmas XML usando huellas digitales 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 Cliente produce un error de derreferenciación al generar firmas XAdES: javax.xml.crypto.URIReferenceException: Errores en las primeras versiones de Java 7 producen problemas internos de derreferenciación al generar firmas XAdEScuandose configura la propiedad “contentTypeOid”. Estos errores de Java quedan solucionados en Java 7 u4. Actualice a esta versión de java 7 o superior para solventar el problema.
 

El Cliente no permite la firma de PDF con ciertos certificados

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.

Como la firma incluye la cadena de certificación completa, si esta es muy extensa puede llegar a agotarse este espacio y resultar en una firma inválida o corrupta. Si esto le ocurre, por favor, póngase en contacto con el servicio de atención a los usuarios del Cliente @firma enviando una copia de su certificado de firma y la cadena de confianza completa. Tenga siempre mucho cuidado de no enviar jamás las partes privadas de los certificados.

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.

Para el uso del repositorio de Mozilla Firefox en Mac OS X es necesario que las bibliotecas NSS estén situadas dentro de una ruta de carga de bibliotecas, pero Firefox al instalarse en Mac OS X las instala en su propio directorio, sin añadir este a la lista de rutas de carga de bibliotecas.
Para sortear esta dificultad, el Cliente @firma, mediante su componente instalador (BootLoader), intenta crear enlaces simbólicos de estas bibliotecas desde el directorio de Firefox a /usr/lib, carpeta dentro de la lista de directorios de carga de bibliotecas. Para realizar esta copia, se necesitan ciertos privilegios, y es por esta razón por la que se solicita la contraseña de usuario privilegiado.

Para más información consulte el Manual de Integrador y la Guía de incidencias del Cliente de Firma.
 

No es posible acceder al almacén de Mozilla Firefox 11 y superiores

Mozilla Firefox 11 introduce cambios en sus bibliotecas de acceso al almacén de certificados. Estos cambios pueden afectar al Cliente @firma impidiéndole acceder a su almacén en sistemas en los que no es posible cargar estas bibliotecas.
 

Existen múltiples motivos por lo que pueden no cargarse las bibliotecas de forma correcta. Si no puede acceder al almacén de certificados de Mozilla Firefox, pruebe a agregar el directorio de bibliotecas de Firefox en el PATH del sistema (consulte las instrucciones de su sistema operativo concreto).
 

Tenga en consideración:
• Debe agregar la ruta del directorio principal de Firefox.
• Si cuenta con varias versiones de Firefox asegúrese de indicar la ruta de la versión con la que vaya a utilizar el Cliente @firma y no agregue más de una.
• La arquitectura del navegador debe ser la misma que la de Java. Preferiblemente, utilice versiones de Mozilla Firefox y Java de 32 bits.
 

En versiones antiguas de Internet Explorer no es posible tener simultáneamente abiertas dos o más páginas que contengan diferentes instancias del Cliente @firma

Es posible que en versiones 7 y anteriores de Internet Explorer abrir una segunda página que contenga el Cliente @firma teniendo otra ya abierta ocasione fallos de carga en la segunda o un malfuncionamiento general en ambas.
Actualice a la última versión de Internet Explorer disponible para su sistema operativo Windows y a al menos la versión 6u30 del entorno de ejecución de Java (JRE) para sortear estos problemas. Si por cualquier motivo no puede actualizar Internet Explorer pruebe a usar otro navegador Web, como Google Chrome.

El Cliente no Funciona Correctamente 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 Cliente deja de funcionar por completo cuando estoy utilizándolo a la vez que una aplicación nativa Windows que hace uso de una tarjeta inteligente

Algunas aplicaciones nativas de Windows que hacen uso de tarjetas inteligentes como el DNIe (aplicación de escritorio, controles ActiveX en páginas Web de Internet Explorer…) interfieren en el funcionamiento de las bibliotecas SunMSCAPI de Java para el uso de los certificados del sistema operativo. Esta interferencia provoca que cualquier intento de una aplicación Java de acceder al almacén de certificados de Windows cuando se tiene insertada la tarjeta inteligente en el lector mientras la otra aplicación esté también ejecutándose, genere un error interno en la máquina virtual de Java que cierra instantáneamente la aplicación 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, debe intentar evitarse la situación en donde una aplicación utilice una tarjeta inteligente a la vez que se usa el cliente de firma. Para hacerlo, conviene separar el uso de las dos aplicaciones que acceden a la tarjeta mediante la extracción y reinserción de la misma en el lector o simplemente cerrando el resto de las aplicaciones mientras se usa una de ellas.
 

Si llegase a producirse este error, es posible que necesite cerrar la aplicación Windows que produce la incompatibilidad y reiniciar la aplicación (página Web) que integra el cliente @firma.

No es posible acceder al almacén de Firefox en sistemas Windows con Java 6u32 o superior y Java 7u4 o superior

La JRE de Oracle para Windows utiliza a partir de las versiones u32 de Java 6 y u4 de Java 7 el entorno de ejecución de Visual C++ 2010. El Cliente @firma no podrá acceder al almacén de Firefox si no cuenta con este entorno de ejecución instalado en su sistema. Puede descargarlo desde:
http://www.microsoft.com/download/en/details.aspx?id=5555
 

El cliente no permite usar el DNIe ni otros dispositivos seguros de creación de firmas para abrir sobres digitales

Ciertos emisores de certificados residentes en dispositivos seguros de creación de firma limitan en origen el uso que se les puede dar a estos.

En el caso del DNIe (y otros dispositivos), no se permite su uso para abrir sobres digitales por no estar ese uso autorizado por el emisor. Debe siempre evitar enviar sobres digitales a particulares si no está seguro de que sus certificados (en su parte privada) van a permitir posteriormente su apertura.

No es posible firmar una página Web con el formato XMLDSig/XAdES Enveloped

XAdES/XMLDSig Enveloped solo admite firmar ficheros XML, y no todas las páginas HTML son 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.

Alguno de los formatos de firma generados con el Cliente @firma no validan adecuadamente en otras plataformas.

Compruebe siempre las matrices de compatibilidad del cliente para verificar que los formatos no están sujetos a problemas de adecuación con normativas/estándares (cuando esto ocurra estará así indicado) y cuáles de los que no presentan estos problemas están soportados por su 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.

Este error ocurre al usar un filtro de certificados mediante el método deprecado “setCertFilter(String)” o “setMandatoryCertificateCondition(String)”.
Al concatenar/anidar múltiples expresiones de este tipo se produce un error en la JVM que obliga a desactivar el filtro. Debe evitarse el uso de filtros con múltiples expresiones.
Es recomendable migrar las aplicaciones al nuevo sistema de filtros basado en la RFC 2254. Pueden establecerse filtros de este tipo mediante el método “setCertFilterRFC2254(String, String, boolean)”.
 

Cuando se despliega el Cliente en entornos donde las páginas HTML se generan dinámicamente no es posible cargar el Applet

Las páginas HTML provistas como ejemplo necesitan ciertos cambios cuando se quiere desplegar el Cliente en servidores donde las páginas se generan dinámicamente (como por ejemplo, Portlets en un Servidor de Portales):
• Las bibliotecas Java del cliente (JAR) deben situarse en una dirección estática dentro del servidor Web, como por ejemplo: http://dirección/directorio_clases
• 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 a los instalables. *
* Si no se establece, supone que estan en el mismo directorio (que el HTML). *
******************************************************************************/
var baseDownloadURL = http://direccion/directorio_clases;

/*******************************************************************************
* Ruta al instalador. *
* Si no se establece, supone que estan en el mismo directorio (que el HTML). *
******************************************************************************/
var base = http://direccion/directorio_clases;

El Cliente de @firma, en su primera ejecución, copia ciertos ficheros al disco duro del usuario para garantizar una correcta ejecución. Estos ficheros son en gran mayoría bibliotecas binarias nativas, aunque si el usuario utiliza el entorno de ejecución de Java en su versión 5 también se actualizan ciertas clases Java de este. Concretamente, la lista de ficheros instalados es la siguiente:

• Java 5 y superiores
Atos Origin Windows Short Path Name Utility (solo se instala en sistemas Windows). Necesaria únicamente para el soporte de los almacenes de claves de Mozilla / Firefox. Se encuentra en el fichero comprimido ShortPathName.zip. Directorio de instalación: $HOME/afirma.5/aoutil/
- ShortPathName.dll
Java Deploy Utility Library for Windows (solo se instala en sistemas Windows). Se encuentra en el fichero comprimido deploy.zip. Directorio de instalación: $HOME/afirma.5/aoutil/
- aodeploy.dll

• Únicamente Java 5 (no se necesitan en versiones superiores)
Paquete de compatibilidad del cliente con Java 5 (Linux/Windows). Necesario para hacer uso desde Java 5 de las funcionalidades incorporadas en las versiones actuales de Java. Este paquete es obligatorio cuando se ejecuta el cliente desde esta versión de Java. Directorio de instalación: $JAVA_HOME/lib/endorsed
- afirma_5_java_5.jar
JavaMS-CAPI Native Library (solo se instala en sistemas Windows). Necesaria únicamente para el soporte de los almacenes de claves de Windows / Internet Explorer. Se encuentra en el fichero comprimido capi.zip. Directorio de instalación: $JAVA_HOME/bin/
- sunmscapi.dll
Entorno de ejecución de Microsoft Visual C++ 7.1 (solo se instala en sistemas Windows). Necesaria únicamente para el soporte de los almacenes de claves de Windows / Internet Explorer, es una dependencia derivada de la biblioteca anterior. Se encuentra en el fichero comprimido msvcr71.zip. Directorio de instalación: $LIBRARY_PATH/
- msvcr71.dll
Java MS-CAPI Provider (solo se instala en sistemas Windows). Necesaria únicamente para el soporte de los almacenes de claves de Windows / Internet Explorer. Se encuentra en el fichero comprimido mscapiJar.zip. Directorio de instalación: $JAVA_HOME/lib/ext/
- sunmscapi.jar
En los directorios de instalación, las siguientes cadenas representan a directorios del sistema operativo dependientes de la instalación:
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 Directorio de instalación del entorno de ejecución 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)
De los tres directorios, el primero no presenta necesidades especiales respecto a permisos, ya que el usuario siempre tiene los apropiados sobre él, pero los otros dos pueden estar restringidos a operaciones de lectura, ejecución o escritura, lo cual puede provocar una instalación 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. Actualización a Java 6 (solución recomendada).
2. Cambio de los permisos de usuario de los directorios afectados.
a. Consulte el manual de usuario de su sistema operativo para los procedimientos de cambio de permisos en directorios.
3. Instalación manual de las bibliotecas.
a. Debe descomprimir los ficheros comprimidos ZIP (consulte el manual de su sistema operativo para los procedimientos de descompresión de ficheros ZIP) en las carpetas apropiadas.
b. Tras la descompresión debe igualmente ajustar los permisos de los directorios y las bibliotecas descomprimidas:
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.