Cliente@firma

O cliente de firma é unha aplicación cliente de Firma Electrónica que se executa no PC do usuario. Está baseado en Applets Java, polo que é necesario ter instalada a máquina virtual de Java, que será a contorna onde se executará dita aplicación

Basicamente, o cliente recibe datos e devólveos asinados, utilizando para iso os certificados instalados no almacén de certificados (keystore) do navegador onde se estea executando nese momento. A razón pola que se executa no cliente é porque a codificación da firma electrónica efectúase no computador do usuario, utilizando a clave privada do certificado seleccionado, que reside no seu PC.

Se o seu certificado reside nun cartón intelixente (DNIe) ou tokenUSB, estes son cargados automaticamente no almacén de certificados a través dos controladores (drivers) dos dispositivos, polo que serán accesibles desde o cliente de firma.

O cliente de firma é unha Applet Java. Este tipo de aplicación ten a peculiaridade que se executa sempre no computador do usuario; para executalo, o navegador debe soportar JAVA (trátase dunha tecnoloxía para aplicacións software independente da plataforma) utilizando o que se chama a Contorna de Execución de Java (JRE) que será onde se execute o cliente de firma.

Para que unha Applet Java poida acceder aos recursos protexidos do PC do usuario, como ler ficheiros localmente ou realizar a firma electrónica, este debe ir asinado dixitalmente pola compañía que o desenvolveu, e só se o usuario confía nesa compañía (ao utilizar unha applet asinado, o usuario debe aceptar unha xanela de advertencia de seguridade na que se lle indica quen é o propietario da aplicación) o cliente executarase.

O cliente de firma está asinado cun certificado do Ministerio da Presidencia. Os detalles do certificado móstranse a seguir:

ASUNTO:
• SERIALNUMBER=S2811001C,
• CN=Asina Código. Mpr. D.X. Impulso Da Administracion Electronica,
• OU=D.X. Para O Impluso Da Administracion Electronica,
• Ou=Ministerio Da Presidencia,
• L=Madrid,
• ST=Madrid,
• C=É

EMISOR:
• CN=AC Camerfirma Codesign v2,
• Ou=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=É

Os requisitos mínimos de uso do Cliente de Firma son os seguintes:

Os navegadores soportados ata o momento son:

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

Os sistemas operativos soportados son:
• Windows XP SP3 / Vista SP2 / 7 SP1 / Server 2003 SP2 / Server 2008 SP2 e superiores
• Linux 2.6 (Guadalinex e Ubuntu) e superiores.
• Mac OS X 10.6.8 e 10.7.2 (Snow Leopard e Lion).

JRE:
• JRE 5 (1.5 update 22) ou superior instalada no navegador (só en navegadores compatibles con Java 5). A compatibilidade con Java 5 é unha funcionalidade a extinguir, recoméndase actualizar a Java 6
• JRE 6 ó JRE 7 instalado en el navegador (1.6 update 30 o 7 update 2 recomendadas)
 

O cliente permite crear firmas dixitais en distintos formatos (por defecto CAdES). Globalmente sopórtanse os seguintes formatos e normativas de firma electrónica:

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

O formato pódese cambiar co método setSignatureFormat que recibe como parámetro a cadea que representa ao formato en cuestión.

O variantes EPES dos formatos de firma que as soportan xeraranse automaticamente ao configurar o formato de firma correspondente e unha política de firma (para máis información recoméndase consultar a documentación do Cliente de Firma).
 

A clase “clienteFirma” ten o método “setShowHashMessage” que recibe como parámetro un valor booleano (true ou false) que indica se se mostrará ou non dita xanela.

A variable "baseDownloadURL" especifica a localización onde se atopan os arquivos de instalación, en caso de non se atopar se no mesmo directorio que o HTML. Estes arquivos son os ".ZIP" e os plug-ins do Cliente de Firma. A variable "base" especifica a localización onde se atopan os arquivos do instalador, en caso de non se atopar se no mesmo directorio que o HTML. Estes arquivos son os ".JAR" e o ficheiro "version.properties".

O Cliente de Firma funciona en local, e por tanto, non realiza conexión con ningunha Plataforma de Firma e/ou selaxe de tempo, polo que non é posible xerar firmas con selo de tempo. Unha posibilidade é utilizar de obter as ditas firmas é utilizar o servizo de Upgrade de sinatura da Plataforma @asina, co cal é posible engadir un selo de tempo ás firmas xeradas co Cliente de Firma, así, unha Asina XAdES actualizaríase a XAdES-T.

En ocasións, as xanelas do cliente perden o foco, facendo imposible lainteracción do usuario. Este erro débese a un erro recoñecido por SunMicrosystems a partir do JRE 1.5.0 que bloquea certas xanelas Java en Internet Explorer e Mozilla, perdendo o foco e facendo imposible a interacción co usuario.

En moitos casos este erro liquídase ao cambiar o foco a outras xanelas, ou minimizar/maximizar o navegador, para tentar que recupere o foco, aínda que non sempre resulta efectivo, polo que se deberá reiniciar o navegador e reintentar a operación. En caso de problemas graves con algunha aplicación Web concreta, é recomendable o uso de Internet Explorer, onde o problema aparece en menor medida.

O controlador PKCS#11 do DNIe non admite que se establezan varias sesións de forma simultánea, e se por calquera razón (sesión SSL, etc.) o propio navegador Web Mozilla / Firefox ten xa establecida unha comunicación co DNIe no momento no que o Cliente @asina tamén o necesita, este último queda bloqueado esperando a que en navegador Mozilla /Firefox peche a súa sesión. O peche da sesión contra o DNIe por parte de Mozilla / Firefox pode tardar varios minutos se o usuario non intervén, polo que convén forzar manualmente este peche:
• Extraer o DNIe do lector e volvelo a inserir xusto no momento no que se solicita o contrasinal do Repositorio Central de certificados de Mozilla Firefox (antes de introducila). É posible que Mozilla / Firefox reabra a sesión na reinserción (adiantándose ao Cliente @asina), polo que quizais necesite repetir a operación.
• Podemos indicar a Mozilla / Firefox que peche a sesión pulsando o botón “Log out” tendo o dispositivo “DNIe PKCS#11 Module” seleccionado na xanela “Dispositivos de Seguridade” do menú Opcións de Mozilla Firefox. Do mesmo xeito que no método anterior, ás veces é necesario repetir a operación varias veces, xa que Mozilla / Firefox reabre automaticamente a comunicación co DNIe sen dar tempo ao Cliente @asina a utilizalo. Noutras ocasións, o botón aparece deshabilitado aínda que Mozilla / Firefox teña unha sesión aberta contra o dispositivo, co que non é posible aplicar este método.

Este problema dáse predominantemente en Linux, Solaris e Mac OS X. Non se detectou en ningún caso en ningunha versión de Windows.

Unha solución alternativa en sistemas baseados en UNIX (Linux, Solaris, Mac OSX) é modificar a configuración de OpenSC (produto no que se basea o controlador PKCS#11 do DNIe nestas plataformas indicando que nunca se debe bloquear o acceso aos cartóns intelixentes.

Para realizar esta indicación debe modificar o arquivo de configuración de OpenSC, normalmente situado en /etc./opensc/opensc.conf e asegurarse de que contén unha liña descomentada coa opción lock_inicio de sesión=false; :
# By default, the OpenSC PKCS#11 module will lock your card
# once you authenticate to the card via C_Inicio de sesión.
# 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_Inicio de sesión, non other application can use it, until
# the first is doe 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, e.g. you cannot run both
# Firefox and Thunderbird at the same estafe, if both are
# configured to use your smart card.
#
# Default: true
lock_inicio de sesión = false;

Dado que este cambio pode ter implicacións de seguridade con outros cartóns intelixentes (a seguridade do DNIe non se ve comprometida por el, dado que implementa medidas adicionais de protección, como a implementación da normativa CWA-14890), realice unicamente estas modificacións se está completamente seguro das súas implicacións.

En certas distribucións de Linux (como Guadalinex v6) o cambio non teñen ningún efecto sobre os bloqueos con DNIe, polo que non solucionará o problema).

O cliente actualiza o API Apache Xalan e Apache Xerces de Java 5 polas últimas versións dispoñibles a data de publicación de leste. Estas versións son completamente compatibles coas anteriores incluídas con Java 5, polo que non introducen ningún problema de compatibilidade.

Adicionalmente, se se detecta a versión 5 de JRE instálase o provedor de seguridade SunMSCAPI na súa versión 6, xa que Java 5 orixinalmente non o inclúe. Esta instalación non cambia nin actualiza ningunha funcionalidade, senón que engade posibilidades completamente novas, polo que non é posible que supoña problema de compatibilidade algún.

Durante a creación dun String de Java a partir dun binario obtido á súa vez da decodificación dunha Base64 pódense pervertir os caracteres especiais dos ficheiros XML se se indica unha codificación errónea no construtor da clase String. A solución máis rápida é non indicar codificación e confiar nas capacidades de Java de auto-detección de formato de caracteres. Se este auto-detección de Java segue proporcionando resultados incorrectos sempre pode obter o XML directamente como texto no canto de en Base64 usando o método getSignatureText() no canto de getSignatureBase64Encoded().

Cando se introduce mal o PIN do DNIe, ocorre que o navegador non detecta os seus certificados, mesmo aínda que posteriormente o usuario si o introduza correctamente.

O problema vén do CSP (Cryptographic Service Provider) do DNI electrónico e a mellor forma de solucionalo é extraer e inserir o DNIe no lector de cartón e volverse a autenticar.

No caso de Mozilla Firefox, é posible que deba pechar e volver abrir o navegador para reiniciar a sesión do cliente e detéctense os certificados.

Ás veces pode ocorrer que o navegador non detecta a extracción ou introdución do DNIe (ou outro cartón intelixente) no lector, polo que se non introducimos o cartón previamente a que arrínquese o cliente de firma, non se atopará o certificado. Outro posible caso é que unha vez cargado o cliente, extráiase o cartón e, ao realizar unha operación de firma, o navegador mostre os certificados do cartón (aínda que xa non estea presente) fallando ao tentar utilizalo.

Este é un problema do navegador na xestión dos dispositivos criptográficos (PKCS#11 para Mozilla e CSP para Internet Explorer), que non informa á sesión aberta no almacén de certificados dos cambios que se producen no mesmo.

A solución máis rápida ao problema é o inserir o cartón antes de que se produza a carga do cliente de firma.

Esta aplicación de Portelo Único da Seguridade Social modifica partes do JRE substituíndo bibliotecas vitais para o Cliente @asina por versións xa obsoletas.

No caso de que necesite inter-operar o Cliente @asina coa aplicación de Portelo Único da Seguridade Social, por favor, abra unha incidencia contra esta última.

Consulte a sección 13.1 do manual do integrador para máis información sobre o despregamento do Cliente de Firma en servidores Web que requiren identificación dos usuarios mediante certificado cliente.

O cliente necesita, dentro da rama Java 5, polo menos a versión 1.5ou18 (recoméndase encarecidamente a actualización a Java 6ou18 ou polo menos Java 5ou22). Se está a usar versións de Java anteriores a 1.5ou18 actualice a súa contorna de execución de Java (JRE) a unha versión máis moderna.

O Cliente non asina as follas de estilo dos ficheiros XML: A versión actual do Cliente de Firma si permite asinas follas de estilo, dado que as follas de estilo dun XML poden declararse de distintas formas, o cliente adopta distintas estratexias para cada forma de declaración e segundo a variante de firma.

Asínalas XMLDSig xeradas non son compatibles con SOAP: Esta funcionalidade está en estudo para ser incluída en futuras versións do Cliente.

Certos validadores non aceptan algunhas das firmas xeradas polo Cliente @asina: Revise con detalle a matriz de compatibilidade e as “NOTAS IMPORTANTES” do manual do Formato XML.

O Cliente non xera asinas XML usando pegadas dixitais XA-2: O erro de Java 6845600 (http://bugs.sun.com/view_bug.do?erro_ide=6845600) afecta á xeración de firmas XML con XA-256 e XA-512. Para sortear estes problemas debe usar Java 6ou30 ou Java 7ou2..
 

O Cliente produce un erro de derreferenciación ao xerar asinas XAdES: javax.xml.crypto.URIReferenceException: Erros nas primeiras versións de Java 7 producen problemas internos de derreferenciación ao xerar firmas XAdEScuandose configura a propiedade “contentTypeOid”. Estes erros de Java quedan solucionados en Java 7 ou4. Actualice a esta versión de java 7 ou superior para liquidar o problema.
 

O Cliente non permite a sinatura de PDF con certos certificados

As firmas de documentos PDF realizadas externamente (que é o método utilizado polo Cliente) teñen un tamaño máximo de octetos que poden ocupar dentro do PDF.

Como a firma inclúe a cadea de certificación completa, se esta é moi extensa pode chegar a esgotarse este espazo e resultar nunha firma inválida ou corrupta. Se isto ocórrelle, por favor, póngase en contacto co servizo de atención aos usuarios do Cliente @asina enviando unha copia do seu certificado de firma e a cadea de confianza completa. Teña sempre moito coidado de non enviar xamais as partes privadas dos certificados.

Ao cargar o Cliente @asina aparece o compoñente instalador solicitando a introdución do contrasinal de usuario privilexiado, pero ou non desexo introducila por motivos de seguridade ou aínda que a introduza o proceso termina en erro.

Para o uso do repositorio de Mozilla Firefox en Mac OS X é necesario que as bibliotecas NSS estean situadas dentro dunha ruta de carga de bibliotecas, pero Firefox ao instalarse en Mac OS X instálaas no seu propio directorio, sen engadir este a a lista de rutas de carga de bibliotecas.
Para sortear esta dificultade, o Cliente @asina, mediante o seu compoñente instalador (BootLoader), tenta crear ligazóns simbólicas destas bibliotecas desde o directorio de Firefox a /usr/lib, cartafol dentro da lista de directorios de carga de bibliotecas. Para realizar esta copia, necesítanse certos privilexios, e é por esta razón pola que se solicita o contrasinal de usuario privilexiado.

Para máis información consulte o Manual de Integrador e a Guía de incidencias do Cliente de Firma.
 

Non é posible acceder ao almacén de Mozilla Firefox 11 e superiores

Mozilla Firefox 11 introduce cambios nas súas bibliotecas de acceso ao almacén de certificados. Estes cambios poden afectar o Cliente @asina impedíndolle acceder ao seu almacén en sistemas nos que non é posible cargar estas bibliotecas.
 

Existen múltiples motivos polo que poden non cargarse as bibliotecas de forma correcta. Se non pode acceder ao almacén de certificados de Mozilla Firefox, probe a agregar o directorio de bibliotecas de Firefox no PATH do sistema (consulte as instrucións do seu sistema operativo concreto).
 

Teña en consideración:
• Debe agregar a ruta do directorio principal de Firefox.
• Se conta con varias versións de Firefox asegúrese de indicar a ruta da versión coa que vaia a utilizar o Cliente @asina e non agregue máis dunha.
• A arquitectura do navegador debe ser a mesma que a de Java. Preferiblemente, utilice versións de Mozilla Firefox e Java de 32 bits.
 

En versións antigas de Internet Explorer non é posible ter simultaneamente abertas dúas ou máis páxinas que conteñan diferentes instancias do Cliente @asina

É posible que en versións 7 e anteriores de Internet Explorer abrir unha segunda páxina que conteña o Cliente @asina tendo outra xa aberta ocasione fallos de carga na segunda ou un malfuncionamiento xeral en ambas.
Actualice á última versión de Internet Explorer dispoñible para o seu sistema operativo Windows e a polo menos a versión 6ou30 da contorna de execución de Java (JRE) para sortear estes problemas. Se por calquera motivo non pode actualizar Internet Explorer probe a usar outra navegador Web, como Google Chrome.

O Cliente non Funciona Correctamente en Windows sobre arquitectura IA64 (Intel Itanium)

A arquitectura IA64 en Windows non está soportada polo Cliente e non o estará nun futuro próximo.

O Cliente deixa de funcionar por completo cando estou ao utilizar á vez que unha aplicación nativa Windows que fai uso dun cartón intelixente

Algunhas aplicacións nativas de Windows que fan uso de cartóns intelixentes como o DNIe (aplicación de escritorio, controis ActiveX en páxinas Web de Internet Explorer…) interferen no funcionamento das bibliotecas SunMSCAPI de Java para o uso dos certificados do sistema operativo. Esta interferencia provoca que calquera intento dunha aplicación Java de acceder ao almacén de certificados de Windows cando se ten inserida o cartón intelixente no lector mentres a outra aplicación estea tamén executándose, xere un erro interno na máquina virtual de Java que pecha instantaneamente a aplicación afectada.
 

Este é un problema xerado por aplicacións nativas Windows que acceden a CAPI por medios non recomendados e por defectos da biblioteca SunMSCAPI, encargada do acceso ao almacén de certificados de Windows, que non pode ser tratado, que impiden operar cando se realizan estes accesos non recomendados.
 

En xeral, debe tentar evitarse a situación onde unha aplicación utilice un cartón intelixente á vez que se usa o cliente de firma. Para facelo, convén separar o uso das dúas aplicacións que acceden ao cartón mediante a extracción e reinserción da mesma no lector ou simplemente pechando o resto das aplicacións mentres se usa unha delas.
 

Se chegase a producirse este erro, é posible que necesite pechar a aplicación Windows que produce a incompatibilidade e reiniciar a aplicación (páxina Web) que integra o cliente @asina.

Non é posible acceder ao almacén de Firefox en sistemas Windows con Java 6ou32 ou superior e Java 7ou4 ou superior

O JRE de Oracle para Windows utiliza a partir das versións ou32 de Java 6 e ou4 de Java 7 a contorna de execución de Visual C++ 2010. O Cliente @asina non poderá acceder ao almacén de Firefox se non conta con esta contorna de execución instalado no seu sistema. Pode descargalo desde:
http://www.microsoft.com/download/en/details.aspx?ide=5555
 

O cliente non permite usar o DNIe nin outros dispositivos seguros de creación de firmas para abrir sobres dixitais

Certos emisores de certificados residentes en dispositivos seguros de creación de firma limitan en orixe o uso que se lles pode dar a estes.

No caso do DNIe (e outros dispositivos), non se permite o seu uso para abrir sobres dixitais por non estar ese uso autorizado polo emisor. Debe sempre evitar enviar sobres dixitais a particulares se non está seguro de que os seus certificados (na súa parte privada) van permitir posteriormente a súa apertura.

Non é posible asinar unha páxina Web co formato XMLDSig/XAdES Enveloped

XAdES/XMLDSig Enveloped só admite asinar ficheiros XML, e non todas as páxinas HTML son compatibles XML.

Comprobe se as páxinas HTML que desexa asinar cumpren estritamente co formato XHTML (que si é compatible XML) e se non seleccione outro formato de firmas.

Algún dos formatos de firma xerados co Cliente @asina non validan adecuadamente noutras plataformas.

Comprobe sempre as matrices de compatibilidade do cliente para verificar que os formatos non están suxeitos a problemas de adecuación con normativas/estándares (cando isto ocorra estará así indicado) e cales dos que non presentan estes problemas están soportados pola súa plataforma validadora.

Algúns dispositivos de creación de firma non funcionan coas funcionalidades de firma multi-fase do Cliente.

Estas limitacións son impostas polos fabricantes dos dispositivos de creación de firmas e non é posible sortealas. Consulte co fabricante do seu dispositivo de creación de firmas para comprobar que funcionalidades poden estar restrinxidas.

A configuración de filtros de certificados produce un erro cando se establece un filtro de gran tamaño.

Este erro ocorre ao usar un filtro de certificados mediante o método deprecado “setCertFilter(String)” ou “setMandatoryCertificateCondition(String)”.
Ao concatenar/aniñar múltiples expresións deste tipo prodúcese un erro na JVM que obriga a desactivar o filtro. Debe evitarse o uso de filtros con múltiples expresións.
É recomendable migrar as aplicacións ao novo sistema de filtros baseado no RFC 2254. Poden establecerse filtros deste tipo mediante o método “setCertFilterRFC2254(String, String, boolean)”.
 

Cando se desprega o Cliente en contornas onde as páxinas HTML xéranse dinamicamente non é posible cargar a Applet

As páxinas HTML provistas como exemplo necesitan certos cambios cando se quere despregar o Cliente en servidores onde as páxinas se xeran dinamicamente (por exemplo, Portlets nun Servidor de Portais):
• As bibliotecas Java do cliente (JAR) deben situarse nunha dirección estática dentro do servidor Web, por exemplo: http://dirección/directorio_clases
• O Javascript (as bibliotecas JS) debe incluírse dentro da páxina que invoca á Applet e pode xerarse dinamicamente, pero debe editarse o ficheiro constantes.js para indicar a súa localización mediante un URL absoluta:

/*******************************************************************************
* Ruta aos instalables. *
* Se non se establece, supón que estan no mesmo directorio (que o HTML). *
******************************************************************************/
var baseDownloadURL = http://direccion/directorio_clases;

/*******************************************************************************
* Ruta ao instalador. *
* Se non se establece, supón que estan no mesmo directorio (que o HTML). *
******************************************************************************/
var base = http://direccion/directorio_clases;

O Cliente de @firma, na súa primeira execución, copia certos ficheiros ao disco duro do usuario para garantir unha correcta execución. Estes ficheiros son en gran maioría bibliotecas binarias nativas, aínda que se o usuario utiliza a contorna de execución de Java na súa versión 5 tamén se actualizan certas clases Java de leste. Concretamente, a lista de ficheiros instalados é a seguinte:

• Java 5 e superiores
Atos Origin Windows Short Path Name Utility (só instálase en sistemas Windows). Necesaria unicamente para o soporte dos almacéns de claves de Mozilla / Firefox. Atópase no ficheiro comprimido ShortPathName.zip. Directorio de instalación: $HOME/afirma.5/aoutil/
- ShortPathName.dll
Java Deploy Utility Library for Windows (só instálase en sistemas Windows). Atópase no ficheiro comprimido deploy.zip. Directorio de instalación: $HOME/afirma.5/aoutil/
- aodeploy.dll

• Unicamente Java 5 (non se necesitan en versións superiores)
Paquete de compatibilidade do cliente con Java 5 (Linux/Windows). Necesario para facer uso desde Java 5 das funcionalidades incorporadas nas versións actuais de Java. Este paquete é obrigatorio cando se executa o cliente desde esta versión de Java. Directorio de instalación: $JAVA_HOME/lib/endorsed
- afirma_5_java_5.jar
JavaMS-CAPI Native Library (só instálase en sistemas Windows). Necesaria unicamente para o soporte dos almacéns de claves de Windows / Internet Explorer. Atópase no ficheiro comprimido capi.zip. Directorio de instalación: $JAVA_HOME/bin/
- sunmscapi.dll
Contorna de execución de Microsoft Visual C++ 7.1 (só instálase en sistemas Windows). Necesaria unicamente para o soporte dos almacéns de claves de Windows / Internet Explorer, é unha dependencia derivada da biblioteca anterior. Atópase no ficheiro comprimido msvcr71.zip. Directorio de instalación: $LIBRARY_PATH/
- msvcr71.dll
Java MS-CAPI Provider (só instálase en sistemas Windows). Necesaria unicamente para o soporte dos almacéns de claves de Windows / Internet Explorer. Atópase no ficheiro comprimido mscapiJar.zip. Directorio de instalación: $JAVA_HOME/lib/ext/
- sunmscapi.jar
Nos directorios de instalación, as seguintes cadeas representan a directorios do sistema operativo dependentes da 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 da contorna de execución de Java
3. $LIBRARY_PATH Directorio de bibliotecas do sistema (por exemplo, /lib nun sistema Linux ou C:\Windows\SYSTEM32 nun sistema MS-Windows 32 Bits)
Do tres directorios, o primeiro non presenta necesidades especiais respecto de permisos, xa que o usuario sempre ten os apropiados sobre el, pero os outros dous poden estar restrinxidos a operacións de lectura, execución ou escritura, o cal pode provocar unha instalación errada.
Dado que os directorios suxeitos a necesidades de permisos son usados unicamente se o usuario utiliza a versión 5 da contorna de execución de Java, existen dúas posibilidades para resolver os posibles fallos de instalación:
1. Actualización a Java 6 (solución recomendada).
2. Cambio dos permisos de usuario dos directorios afectados.
a. Consulte o manual de usuario do seu sistema operativo para os procedementos de cambio de permisos en directorios.
3. Instalación manual das bibliotecas.
a. Debe descomprimir os ficheiros comprimidos ZIP (consulte o manual do seu sistema operativo para os procedementos de descompresión de ficheiros ZIP) nos cartafoles apropiados.
b. Tras a descompresión debe igualmente axustar os permisos dos directorios e as bibliotecas descomprimidas:
i. Os directorios deben ter permisos de lectura, non é necesario permisos de escritura.
ii. As bibliotecas necesitan permisos de lectura e execución, non é necesario permisos de escritura.