accesskey_mod_content

Cliente@firma

El client de signatura és una aplicació client de Signatura Electrònica que s'executa en el PC de l'usuari. Està basat en Applets Java, per la qual cosa és necessari tenir instal·lada la màquina virtual de Java, que serà l'entorn on s'executarà aquesta aplicació.

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

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

El client de signatura és un Applet Java. Aquest tipus d'aplicació té la peculiaritat que s'executa sempre en l'ordinador de l'usuari; per 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'executi el client de signatura.

Perquè un Applet Java pugui accedir als recursos protegits del PC de l'usuari, com llegir fitxers localment o realitzar la signatura electrònica, aquest ha d'anar signat digitalment per la companyia que ho ha desenvolupat, i només si l'usuari confia en aquesta companyia (en utilitzar un applet signat, l'usuari ha d'acceptar una finestra d'advertiment de seguretat en la qual se li indica qui és el propietari de l'aplicació) el client s'executarà.

El client de signatura està signat amb un certificat del Ministeri de la Presidència. Els detalls del certificat es mostren a continuació:

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

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

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

Els navegadors suportats fins al moment són:

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

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

JRE:
• JRE 5 (1.5 update 22) o superior 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 signatures digitals en diferents formats (per defecte CAdES). Globalment se suporten els següents formats i normatives de signatura electrònica:

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

El 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 signatura que les suporten es generaran automàticament en configurar el format de signatura corresponent i una política de signatura (para més informació es recomana consultar la documentació del Client de Signatura).
 

La classe “clienteFirma” té el mètode “setShowHashMessage” que rep com a paràmetre un valor booleà (true o false) que indica si es mostrarà o no aquesta finestra.

La variable "baseDownloadURL" especifica la ubicació on es troben els arxius d'instal·lació, en cas de no es trobar-se en el mateix directori que l'HTML. Aquests arxius són els ".ZIP" i els plug-ins del Client de Signatura. La variable "base" especifica la ubicació on es troben els arxius de l'instal·lador, en cas de no es trobar-se en el mateix directori que l'HTML. Aquests arxius són els ".JAR" i el fitxer "version.properties".

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

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

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

El controlador PKCS#11 del DNIe no admet que s'estableixin diverses sessions de forma simultània, i si per qualsevol raó (sessió SSL, etc.) el propi navegador Web Mozilla / Firefox té ja establerta una comunicació amb el DNIe al moment en el qual el Client @signa també ho necessita, aquest últim es queda bloquejat esperant al fet que en navegador Mozilla /Firefox tanqui la seva sessió. El tancament de la sessió contra el DNIe per part de Mozilla / Firefox pot trigar diversos minuts si l'usuari no intervé, per la qual cosa convé forçar manualment aquest tancament:
• Extreure el DNIe del lector i tornar-ho a inserir just al moment en el qual se sol·licita la contrasenya del Repositori Central de certificats de Mozilla Firefox (abans d'introduir-la). És possible que Mozilla / Firefox reobri la sessió en la reinserció (avançant-se al Client @signa), per la qual cosa potser necessiti repetir l'operació.
• Podem indicar a Mozilla / Firefox que tanqui la sessió prement el botó “Registre out” tenint el dispositiu “DNIe PKCS#11 Moduli” seleccionat en la finestra “Dispositius de Seguretat” del menú Opcions de Mozilla Firefox. Igual que en el mètode anterior, de vegades és necessari repetir l'operació diverses vegades, ja que Mozilla / Firefox reobre automàticament la comunicació amb el DNIe sense donar temps al Client @signa a utilitzar-ho. En altres ocasions, el botó apareix deshabilitat encara que Mozilla / Firefox tingui una sessió oberta contra el dispositiu, amb el que no és possible aplicar aquest mètode.

Aquest problema es dona predominantment en Linux, Solaris i Mac US X. No s'ha detectat en cap cas en cap versió de Windows.

Una solució alternativa en sistemes basats en UNIX (Linux, Solaris, Mac OSX) és modificar la configuració d'OpenSC (producte en el qual es basa el controlador PKCS#11 del DNIe en aquestes plataformes indicant que mai s'ha de bloquejar l'accés a les targetes intel·ligents.

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

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

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

El client actualitza els API Apatxe Xalan i Apatxe Xerces de Java 5 per les últimes versions disponibles a data de publicació d'est. Aquestes versions són completament compatibles amb les anteriors incloses amb Java 5, per la qual cosa no introdueixen cap problema de compatibilitat.

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

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 aquesta acte-detecció de Java segueix proporcionant resultats incorrectes sempre pot obtenir els XML directament com a text en comptes d'en Base64 usant el mètode getSignatureText() en comptes de getSignatureBase64Encoded().

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

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

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

De vegades pot ocórrer que el navegador no detecta l'extracció o introducció del DNIe (o una altra targeta intel·ligent) en el lector, per la qual cosa si no hem introduït la targeta prèviament al fet que s'arrenqui el client de signatura, no es trobarà el certificat. Un altre possible cas és que una vegada carregat el client, s'extregui la targeta i, en realitzar una operació de signatura, el navegador mostri els certificats de la targeta (encara que ja no estigui present) fallant en intentar utilitzar-ho.

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 produeixen en el mateix.

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

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

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

Consulti les secció 13.1 del manual de l'integrador para més informació sobre el desplegament del Client de Signatura en servidors Web que requereixen 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 actualitzi el seu entorn d'execució de Java (JRE) a una versió més moderna.

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

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

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

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

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

El Client no permet la signatura de PDF amb certs certificats

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

En carregar el Client @signa apareix el component instal·lador sol·licitant la introducció de la contrasenya d'usuari privilegiat, però o no desitjo introduir-la per motius de seguretat o encara que la introdueixi 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 estiguin situades dins d'una ruta de càrrega de biblioteques, però Firefox en instal·lar-se en Mac US X les instal·la en el seu propi directori, sense afegir aquest a la llista de rutes de càrrega de biblioteques.
Per sortejar aquesta dificultat, el Client @signa, mitjançant el seu component instal·lador (BootLoader), intenta crear enllaços simbòlics d'aquestes biblioteques des del directori de Firefox a /usr/lib, carpeta dins de la llista de directoris de càrrega de biblioteques. Per realitzar aquesta còpia, es necessiten certs privilegis, i és per aquesta raó per la qual se sol·licita la contrasenya d'usuari privilegiat.

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

 

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

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

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

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

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

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

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

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

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

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

Est és un problema generat per aplicacions natives Windows que accedeixen 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 impedeixen operar quan es realitzen aquests accessos no recomanats.
 

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

Si arribés a produir-se aquest error, és possible que necessiti tancar l'aplicació Windows que produeix la incompatibilitat i reiniciar l'aplicació (pàgina Web) que integra el client @signa.

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

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

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

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

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

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

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

Comprovi si les pàgines HTML que desitja signar compleixen estrictament amb el format XHTML (que sí és compatible XML) i si no seleccioni un altre format de signatures.

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

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

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

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

La configuració de filtres de certificats produeix un error quan s'estableix un filtre de gran grandària.

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

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

Les pàgines HTML proveïdes com a exemple necessiten certs canvis quan es vol desplegar el Client en servidors on les pàgines es generen dinàmicament (com per exemple, Portlets en un Servidor de Portals):
• Les biblioteques Java del client (JAR) han de situar-se en una adreça estàtica dins del servidor Web, com per exemple: http://adreça/directori_classes
• El Javascript (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 indicar la seva localització mitjançant una URL absoluta:

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

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

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

• Java 5 i superiors
Atos Origin Windows Short Path Name Utility (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Mozilla / Firefox. Es troba en el fitxer comprimit ShortPathName.zip. Directori d'instal·lació: $HOME/afirma.5/aoutil/
- ShortPathName.dll
Java Deploy Utility Library for Windows (solament s'instal·la en sistemes Windows). Es troba en el fitxer comprimit deploy.zip. Directori d'instal·lació: $HOME/afirma.5/aoutil/
- aodeploy.dll

• Únicament Java 5 (no es necessiten en versions superiors)
Paquet de compatibilitat del client amb Java 5 (Linux/Windows). Necessari per fer ús des de Java 5 de les funcionalitats incorporades en les versions actuals de Java. Aquest paquet és obligatori quan s'executa el client des d'aquesta versió de Java. Directori d'instal·lació: $JAVA_HOME/lib/endorsed
- afirma_5_java_5.jar
JavaMS-CAPI Native Library (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer. Es troba en el fitxer comprimit capi.zip. Directori d'instal·lació: $JAVA_HOME/bin/
- sunmscapi.dll
Entorn d'execució de Microsoft Visual C++ 7.1 (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer, és una dependència derivada de la biblioteca anterior. Es troba en el fitxer comprimit msvcr71.zip. Directori d'instal·lació: $LIBRARY_PATH/
- msvcr71.dll
Java MS-CAPI Provider (solament s'instal·la en sistemes Windows). Necessària únicament per al suport dels magatzems de claus de Windows / Internet Explorer. Es troba en el fitxer comprimit mscapiJar.zip. Directori d'instal·lació: $JAVA_HOME/lib/ext/
- sunmscapi.jar
En els directoris d'instal·lació, les següents cadenes representen a directoris del sistema operatiu dependents de la instal·lació:
1. $HOME Directori d'usuari (per exemple, /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 Directori de biblioteques del sistema (per exemple, /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.
Atès que els directoris subjectes a necessitats de permisos són usats únicament si l'usuari utilitza la versió 5 de l'entorn d'execució de Java, existeixen dues possibilitats per resoldre les possibles fallades d'instal·lació:
1. Actualització a Java 6 (solució recomanada).
2. Canvi dels permisos d'usuari dels directoris afectats.
a. Consulti 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 (consulti el manual del seu sistema operatiu per als procediments de descompressió de fitxers ZIP) a les carpetes apropiades.
b. Després de la descompressió deu igualment ajustar els permisos dels directoris i les biblioteques descomprimides:
i. Els directoris han de tenir permisos de lectura, no és necessari permisos d'escriptura.
ii. Les biblioteques necessiten permisos de lectura i execució, no és necessari permisos d'escriptura.

Punt d'Accés General
Punt d'Accés General

Enllaços relacionatsEnllaços relacionats

Destacats