[jboss-cvs] JBossAS SVN: r70853 - projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES.

Thu Mar 13 19:56:31 EDT 2008

Author: agarcia at jboss.com
Date: 2008-03-13 19:56:31 -0400 (Thu, 13 Mar 2008)
New Revision: 70853

Modified:
   projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_Security_On_JBOSS.po
Log:
PR finished

Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_Security_On_JBOSS.po
===================================================================

--- projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_Security_On_JBOSS.po	2008-03-13 23:48:36 UTC (rev 70852)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/es-ES/J2EE_Security_On_JBOSS.po	2008-03-13 23:56:31 UTC (rev 70853)
@@ -8,7 +8,7 @@
 "Project-Id-Version: J2EE_Security_On_JBOSS\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2007-11-06 22:32+0000\n"
-"PO-Revision-Date: 2008-03-13 15:05+1000\n"
+"PO-Revision-Date: 2008-03-14 09:43+1000\n"
 "Last-Translator: Angela Garcia\n"
 "Language-Team:  <en at li.org>\n"
 "MIME-Version: 1.0\n"
@@ -8083,7 +8083,7 @@
 "This produces a keystore file called <literal>example.keystore</literal>. A "
 "keystore is a database of security keys. There are two different types of "
 "entries in a keystore:"
-msgstr "esto produce un archivo de almacenmiento de llaves llamado <literal>example.keystore</literal>. Un almacenamiento de llaves es una base de datos de llaves de seguridad. Hay dos tipos diferentes de entradas en un almacenamiento de llaves:"
+msgstr "Esto produce un archivo de almacenamiento de llaves llamado <literal>example.keystore</literal>. Un almacenamiento de llaves es una base de datos de llaves de seguridad. Hay dos tipos diferentes de entradas en un almacenamiento de llaves:"
 
 #. Tag: para
 #: J2EE_Security_On_JBOSS.xml:1932
@@ -8098,7 +8098,7 @@
 "is private keys and their associated certificate chains."
 msgstr ""
 "<emphasis role=\"bold\">key entries</emphasis>: cada entrada tiene información de llaves criptográficas altamente delicada, la cual se almacena en un formato protegido para prevenir acceso no autorizado. Usualmente un llave almacenada en este tipo de entrada es una llave secreta o una llave privada acompañada por la cadena de certificados para la llave pública correspondiente. Las herramientas <literal>keytool</literal> y "
-"<literal>jarsigner</literal> sólo manejan el último tipo de entrada que es llaves privadas y sus cadenas de ceertificados asociados."
+"<literal>jarsigner</literal> sólo manejan el último tipo de entrada que es llaves privadas y sus cadenas de certificados asociados."
 
 #. Tag: para
 #: J2EE_Security_On_JBOSS.xml:1937
@@ -8120,7 +8120,7 @@
 "literal> examples file contents using the keytool shows one self-signed "
 "certificate:"
 msgstr ""
-"Listando el contenido del archivo de ejemplos <literal>src/main/org/jboss/book/security/example.keystore</"
+"El listar el contenido del archivo de ejemplos <literal>src/main/org/jboss/book/security/example.keystore</"
 "literal> utilizando la herramienta de llaves muestra un certificado auto-firmado:"
 
 #. Tag: programlisting
@@ -8208,7 +8208,7 @@
 "RMIClientSocketFactory</literal> que habilitan el uso de RMI sobre sockets encriptados SSL. Las clases de implementación son <literal>org.jboss."
 "security.ssl.RMISSLServerSocketFactory</literal> y <literal>org.jboss."
 "security.ssl.RMISSLClientSocketFactory</literal> respectivamente. Hay dos pasos para habilitar el uso de SSL para acceso RMI para EJBs. Lo primero es habilitar el uso de un almacenamiento de llaves como la base de datos para el cetirifcado del servidor SSL, lo cual se logra configurando un MBean <literal>org.jboss.security.plugins."
-"JaasSecurityDomain</literal>. El descriptor <literal>jboss-service.xml</literal> en el directorio <literal>book/security/ex4</literal> incluye la definición <literal>JaasSecurityDomain</literal> que se muestra en <xref linkend="
+"JaasSecurityDomain</literal>. El descriptor <literal>jboss-service.xml</literal> en el directorio <literal>book/security/ex4</literal> incluye la definición <literal>JaasSecurityDomain</literal> que se muestra en el <xref linkend="
 "\"Using_SSL_with_JBoss_using_JSSE-"
 "A_sample_JaasSecurityDomain_config_for_RMISSL\"/>."
 
@@ -8259,8 +8259,8 @@
 "from the example 4 MBean SAR using the indicated password."
 msgstr ""
 "El <literal>JaasSecurityDomain</literal> es una subclase de la clase estándar "
-"<literal>JaasSecurityManager</literal> que añade las nociones de un alamacenamiento de llaves así como acceso JSSE <literal>KeyManagerFactory</literal> y "
-"<literal>TrustManagerFactory</literal> . Extiende el administrador de seguridad básico para permitir el soporte para SSL y otras operaciones criptográficas que requieren llaves de seguridad. Esta configuración simplemente carga el example.keystore del SAR MBean del ejemplo 4 utilizando la contraseña indicada."
+"<literal>JaasSecurityManager</literal> que añade las nociones de un almacenamiento de llaves así como acceso JSSE <literal>KeyManagerFactory</literal> y "
+"<literal>TrustManagerFactory</literal>. Extiende el administrador de seguridad básico para permitir el soporte para SSL y otras operaciones criptográficas que requieren llaves de seguridad. Esta configuración simplemente carga el example.keystore del SAR MBean del ejemplo 4 utilizando la contraseña indicada."
 
 #. Tag: para
 #: J2EE_Security_On_JBOSS.xml:1954
@@ -8273,7 +8273,7 @@
 "this invoker. The top of the listing shows the <literal>jboss-service.xml</"
 "literal> descriptor that defines the custom <literal>JRMPInovker</literal>"
 msgstr ""
-"El segudno paso es definir una configuración del invocador EJB que utiliza las fábricas del socket RMI de JBossSX que soporta SSL. Para lograr esto necesita definir una configuración personalizada para el <literal>JRMPInvoker</literal> que vimos en <xref linkend=\"EJBs_on_JBoss\"/> así como una configuración EJB que utiliza este invocador. La parte superior de la lista muestra el descriptor <literal>jboss-service.xml</"
+"El segundo paso es definir una configuración del invocador EJB que utiliza las fábricas del socket RMI de JBossSX que soporta SSL. Para lograr esto necesita definir una configuración personalizada para el <literal>JRMPInvoker</literal> que vimos en el <xref linkend=\"EJBs_on_JBoss\"/> así como una configuración EJB que utiliza este invocador. La parte superior de la lista muestra el descriptor <literal>jboss-service.xml</"
 "literal> que define el <literal>JRMPInovker</literal> personalizado."
 
 #. Tag: programlisting
@@ -8496,7 +8496,7 @@
 "truststore using the <literal>javax.net.ssl.trustStore</literal> system "
 "property:"
 msgstr ""
-"La excepción que resulta se esperaba y es el propósito de la versión 4b del ejemplo. Observe que el rastro de la pila de excepciones ha sido modificado para que quepa dentro del formato del libro así que podrá observar algunas diferencias. El punto clave a observar sobre la excepción es que muestra claramente que está utilizando las clases JSSE de Sun para comunicarse con el contenedor EJB de JBoss. La excepción dice que el certificado auto-firmado que está utilizando como certificado del servidor de JBoss no se puede validar como si estuviese firmado por cualquier otra autoridad del certificado predeterminado. Esto se espera ya que el almacenamiento de llaves de la autoridad del certificado predeterminado que se envía junto con el paquete JSSE solo incluye autoridades del ceertificado bien conocidas tal como VeriSign, Thawte y RSA Data Security. Para hacer que el cliente EJB acepte su certificado auto-firmado como válido necesita decirle a las clases JSSE que u!
 tilicen su <literal>example.keystore</literal> como su almacenamiento de confianza. Un almacenamiento de confianza es simplemente un alcenamiento de llaves que contiene certificados de llaves públicas que se utilizan para firmar otros ceertificados. Para lograr esto ejecute el ejemplo 4 utilizando <literal>-Dex=4</literal> "
+"La excepción que resulta se esperaba y es el propósito de la versión 4b del ejemplo. Observe que el rastro de la pila de excepciones ha sido modificado para que quepa dentro del formato del libro así que podrá observar algunas diferencias. El punto clave a observar sobre la excepción es que muestra claramente que está utilizando las clases JSSE de Sun para comunicarse con el contenedor EJB de JBoss. La excepción dice que el certificado auto-firmado que está utilizando como certificado del servidor de JBoss no se puede validar como si estuviese firmado por cualquier otra autoridad del certificado predeterminado. Esto se espera ya que el almacenamiento de llaves de la autoridad del certificado predeterminado que se envía junto con el paquete JSSE solo incluye autoridades del certificado bien conocidas tal como VeriSign, Thawte y RSA Data Security. Para hacer que el cliente EJB acepte su certificado auto-firmado como válido necesita decirle a las clases JSSE que ut!
 ilicen su <literal>example.keystore</literal> como su almacenamiento de confianza. Un almacenamiento de confianza es simplemente un alcenamiento de llaves que contiene certificados de llaves públicas que se utilizan para firmar otros certificados. Para lograr esto ejecute el ejemplo 4 utilizando <literal>-Dex=4</literal> "
 "en vez de <literal>-Dex=4b</literal> para pasar la ubicación del almacenamiento de confianza correcto utilizando la propiedad del sistema <literal>javax.net.ssl.trustStore</literal>:"
 
 #. Tag: programlisting


