![Subscríbeche á nosa Newsletter Subscríbeche á nosa Newsletter](/dam/jcr:39291559-a64f-40b4-82ba-e17bd880fe2b/banner-newsletter-pae.png)
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.
Si 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 é un 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 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 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 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 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. No detectouse 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 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().
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
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 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 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 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 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).
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
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.
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.
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.
Algún dos formatos de firma xerados co Cliente @asina non validan adecuadamente noutras 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.
Algúns dispositivos de creación de firma non funcionan coas funcionalidades de firma multi-fase do 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.
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):
• 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
• 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. *
* Si no se establece, supone que estan en el mismo directorio (que el HTML). *
******************************************************************************/
var baseDownloadURL = http://direccion/directorio_clases;
/*******************************************************************************
* Ruta ao instalador. *
* Si no se establece, supone que estan en el mismo directorio (que el 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 (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 (non se necesitan en versións 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
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 del sistema (por ejemplo, /lib en un sistema Linux o C:\Windows\SYSTEM32 en un 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 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 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.
![Subscríbeche á nosa Newsletter Subscríbeche á nosa Newsletter](/dam/jcr:39291559-a64f-40b4-82ba-e17bd880fe2b/banner-newsletter-pae.png)
![A túa opinión é importante - Enquisa A túa opinión é importante - Enquisa](/dam/jcr:34de006a-b33b-4b02-9247-7fe58af52a90/banner-encuesta.png)
![Subscríbeche á nosa Newsletter Subscríbeche á nosa Newsletter](/dam/jcr:39291559-a64f-40b4-82ba-e17bd880fe2b/banner-newsletter-pae.png)
![A túa opinión é importante - Enquisa A túa opinión é importante - Enquisa](/dam/jcr:34de006a-b33b-4b02-9247-7fe58af52a90/banner-encuesta.png)