accesskey_mod_content

Cliente@firma

  • Escoltar
  • Imprimir PDF
  • Compartir

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 firmats, utilitzant per a açò els certificats instal·lats en el magatzem de certificats (keystore) del navegador on s'estiga executant en eixe moment. La raó per la qual s'executa en el client és perquè la codificació de la firma electrònica s'efectua en l'ordinador de l'usuari, utilitzant la clau privada del certificat seleccionat, que residix en el seu PC.

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

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

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 client de firma està firmat amb un certificat del Ministeri de la Presidència. Els detalls del certificat es mostren a continuació:

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

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

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

Els navegadors suportats fins al moment són:

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

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

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

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

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

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

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

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

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

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

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

El controlador PKCS#11 del DNIe no admet que s'establisquen diverses sessions de forma simultània, i si per qualsevol raó (sessió SSL, etc.) el propi navegador Web Mozilla / Firefox té ja establida una comunicació amb el DNIe en el moment en el qual el Client @firma també ho necessita, este últim es queda bloquejat esperant al fet que en navegador Mozilla /Firefox tanque la seua sessió. El tancament de la sessió contra el DNIe per part de Mozilla / Firefox pot tardar diversos minuts si l'usuari no interven, per la qual cosa convé forçar manualment este tancament:
• 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 tanque la sessió polsant el botó “Registre out” tenint el dispositiu “DNIe PKCS#11 Module” seleccionat en la finestra “Dispositius de Seguretat” del menú Opcions de Mozilla Firefox. Igual que en el mètode anterior, a voltes és necessari repetir l'operació diverses vegades, ja que Mozilla / Firefox reobri automàticament la comunicació amb el DNIe sense donar temps al Client @firma a utilitzar-ho. En altres ocasions, el botó apareix deshabilitat encara que Mozilla / Firefox tinga una sessió oberta contra el dispositiu, amb el que no és possible aplicar este mètode.

Este problema 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 estes plataformes indicant que mai s'ha de bloquejar l'accés a les targetes intel·ligents.

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

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

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

El 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.

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

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 cas de Mozilla Firefox, és possible que haja de tancar i tornar a obrir el navegador per a reiniciar la sessió del client i es detecten els certificats.

A 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.

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

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

Este 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 les secció 13.1 del manual de l'integrador para més informació sobre el desplegament del Client de Firma en servidors Web que requerixen identificació dels usuaris mitjançant certificat client.

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

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

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

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

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

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

El Client no permet la firma de PDF amb certs certificats

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 firma generats amb el Client @firma no validen adequadament en altres plataformes.

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

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

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

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

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

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

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

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

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

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

• Java 5 i superiors
Atos Origin Windows Short Path Name Utility (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Mozilla / Firefox. Es troba en el fitxer comprimit ShortPathName.zip. Directori d'instal·lació: $HOME/afirma.5/aoutil/
- ShortPathName.dll
Java Deploy Utility Library for Windows (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 es necessiten en versions superiors)
Paquet de compatibilitat del client amb Java 5 (Linux/Windows). Necesario per a fer ús des de Java 5 de les funcionalitats incorporades en les versions actuals de Java. Este paquet és obligatori quan s'executa el client des d'esta versió de Java. Directori d'instal·lació: $JAVA_HOME/lib/endorsed
- afirma_5_java_5.jar
JavaMS-CAPI Native Library (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
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 d'usuari del seu sistema operatiu per als procediments de canvi de permisos en directoris.
3. Instal·lació manual de les biblioteques.
a. Ha de descomprimir els fitxers comprimits ZIP (consulte el manual del seu sistema operatiu per als procediments de descompressió de fitxers ZIP) en les carpetes apropiades.
b. Després de la descompressió deu igualment ajustar els permisos dels directoris i les biblioteques descomprimides:
i. 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.

Enllaços relacionatsEnllaços relacionats

Destacats