Signserver Manual 1 0 RC1.Sv - Es

Página No. / Página No.
EJBCA Sign Server, Manual 1 (18)

Puesta en marcha / auhtor Privacidad / confidencialidad
Philip Vendil RESTRINGIDO
Pasa / autorizado fecha fecha versión
07.22.06 1.0 RC1
EJBCA Sign Server
manual
06.07.22

07.22.06 1.0 RC1
1 Introducción / Alcance
El servidor EJBCA de signos es un marco de aplicación firmas de bajo rendimiento para otras aplicaciones. Está pensado para ser
utilizado en entornos en los que se supone claves a ser protegidos en hardware, pero no es posible conectar este hardware a las
aplicaciones empresariales existentes. Otro uso es el de proporcionar un método simplificado para proporcionar firmas en diferentes
aplicación administrada de un lugar en la empresa.
El servidor de suscripción havebeen diseñada para alta disponibilidad y pueden ser agrupados para una máxima fiabilidad. El servidor de suscripción
viene con un RFC 3161 compatible firmante marca de tiempo a atender las solicitudes a través de HTTP o HTTPS autenticada-cliente.
Dibujo 1: Visión general de un conjunto posible de una señal solución de servidor de alta disponibilidad
2 Historial del documento
versión Fecha nombre comentario
0.1 2006-06-04 Philip Vendil La versión inicial de este documento.
1.0 RC1 2006-08-22 Philip Vendil versiones preliminares


07.22.06 1.0 RC1
Tabla de Contenidos
1 Introducción / Alcance .............................................. .................................................. ........................... 2

2 Historial del documento ............................................... .................................................. ............................. 2
3 Inicio rápido de una simple ....................................... servidor de marca de hora ................................................ 4
3.1Required Software ............................................... .................................................. ....................... 4
3.2Installation Pasos ............................................... .................................................. ......................... 4
4 Arquitectura general ............................................... .................................................. ......................... 6
5 firmantes disponibles ............................................... .................................................. .............................. 7
Firmante 5.1Time-stamp ............................................. .................................................. ........................ 7
5.1.1Overview ............................................... .................................................. ............................... 7
Propiedades 5.1.2Available .............................................. .................................................. ............... 7
5.2MRTD firmante ............................................... .................................................. .............................. 8
5.2.1Overview ............................................... .................................................. ............................... 8
6 SignTokens disponibles ............................................... .................................................. ....................... 9
6.1P12SignToken ................................................ .................................................. 9 ............................
6.1.1Overview ............................................... .................................................. ............................... 9
Propiedades 6.1.2Available
........................................................... . .......................................................................................... . 9
6.2PrimeCardHSMSignToken ................................................ .................................................. ......... 9
6.2.1Overview ............................................... .................................................. ............................... 9
7 Configuración de autorización de un tipo .............................................. .................................................. .............. 10
8 Creación e implementación del servidor de suscripción ............................................ ............................................... 10
9 Administrar el servidor de suscripción .............................................. .................................................. ......... 11
10 Haciendo el servidor de suscripción de alta disponibilidad ........................................... 12 ..............................................
Acceso 10.1HTTP requiere un equilibrador de carga ........................................... ........................................... 12
10.2Setting un MySQL Cluster ............................................ .................................................. ...... 12
11 Prueba ................................................ .................................................. ......................................... 15
11.1Automatic JUnit Pruebas de .............................................. .................................................. ............... 15
11.2The cliente de prueba .............................................. .................................................. ......................... 15
Pruebas de 11.3Manual ............................................... .................................................. ........................... 15
12 para desarrolladores ............................................... .................................................. ............................. 15
12.1The ISigner interfaz .............................................. .................................................. ................ 15
12.2The helado de emergencia Interfaz .............................................. .................................................. ......... 15
13 Referencias ................................................ .................................................. .................................... 15

07.22.06 1.0 RC1
3 Inicio rápido de un simple sello de tiempo de servidor
En esta sección se mostrará cómo configurar un servidor de marca de tiempo independiente rápida y sencilla, aceptar solicitudes de sello de
tiempo a través de HTTP sin formato.
3.1 Software necesario
Java 1.5 (o 1.4) (http://java.sun.com) Jboss-4.0.4.GA
(http://www.jboss.org) versión 1.6.5 hormiga
(http://ant.apache.org ) firmar servidor-1,0-beta1 ( http://www.ejbca.org
1-servidor web del almacén de claves en formato Java del almacén de claves (ACA), (marido surethat el certificado del servidor tiene el nombre de
host justo en que es CN)
1 Certificado de raíz del servidor web 1 in der codificación
tienda-sello-llave de la hora en formato PKCS12
3.2 Pasos de la instalación

1. En primer lugar hacer hormiga surethat, Java y JBoss se ha instalado correctamente.
2. Establecer las variables de entorno JAVA_HOME y JBOSS_HOME.
3. Descomprimir el paquete de servidor de suscripción y vaya a su directorio personal.
4. Cambie el nombre del almacén de claves de servidor Web para tomcat.jks al ponerlo en un subdirectorio 'p12'. También colocar el
certificado raíz del servidor web en la codificación DER en el mismo directorio, lo llaman rootcert.cer
5. A continuación, signserver_build.properties editar el archivo. Al menos configurar la propiedad httpsserver.password.
6. Do 'ant deploy' y luego iniciar JBoss (JBOSS_HOME \ bin \ run.sh) en otra consola.
7. Editar los signserver_cli.properties y establece el nombre de host. * Propiedades.
8. Utilice el servidor de suscripción a Clipper Establecer las siguientes propiedades:

(si no es ejecutiva chmod + x uso bin / signserver.sh)
bin \ signserver.sh setProperty 1 DEFAULTTSAPOLICYOID "la <predeterminado policyId>" bin \ signserver.sh setProperty
1 almacén de claves PATH "<ruta a P12 marca de tiempo>" bin \ signserver.sh setProperty 1 almacén de claves
PASSWORD "<contraseña de almacén de claves>" bin \ signserver.sh noauth setProperty 1 AuthType
(En la sección de ruta, utilice '\\' FOR '\' en el entorno de Windows.)


07.22.06 1.0 RC1
a continuación, ejecutar
bin \ signserver.sh getConfig 1
Y vuelva a verificar la configuración con la referencia Propety. (Importante, las propiedades son mayúsculas y minúsculas). Finalmente
la carrera
bin \ signserver.sh recarga

Para activar la configuración.
9. Ejecutar la prueba a cliente ver que todo se ha acabado.
CD dist-cliente
java-jar timeStampClient.jar " http: // localhost: 8080 / Sign Server / TSA signerId = 1 "
El mensaje de "petición de marca horaria Validado" debe aparecer una vez por segundo. También puedes ver JBOSS_HOME / server
/ default / log / server.log que los mensajes aparecen con éxito.

07.22.06 1.0 RC1
4 Arquitectura general
El servidor de suscripción es un marco diseñado para llevar a cabo diferentes tipos de firmas digitales para diferentes aplicaciones.
Para acceder al servidor de suscripción, hay diferentes opciones dependiendo de la persona que firma utilizado. El firmante de sello de tiempo
utiliza HTTP para el acceso remoto y el MRDT firmante utiliza RMI SSL. Hay dos conceptos principales en el servidor de suscripción y que los
firmantes de hielo (que realiza la firma real y son identificados por un signerId) y el signo de emergencia ¿Qué es una entidad que realiza un
seguimiento de las claves de firma (puede ser software o hardware basado).
Las aplicaciones en el administrada a través de una interfaz de línea de comandos, donde el control de propiedades y el acceso se puede
configurar.
Los documentos que actualmente existen dos modos de autenticación, un cliente autenticado utilizando SSL, donde el número de serie
de cada cliente firmante tiene que estar en la lista de acceso para la firma firmantes a realizar. El otro es un modo no autenticado
donde no hay ningún requisito a los que se solicita una firma.
Un servidor de suscripción puede tener múltiples firmantes para diferentes propósitos.


07.22.06 1.0 RC1
5 firmantes disponibles
Actualmente existen dos tipos de firmantes. El primero es el sello de tiempo firmante Generating RFC 3161 marcas de tiempo que cumplen
utilizando la biblioteca BouncyCastle. El otro es un firmante DVLM la creación de firmas 'Máquina lector de documentos de viaje' utilizando
el algoritmo RSA a partir de datos de pre-rellenados.
Firmante 5,1 sello de tiempo

El firmante de sello de tiempo tiene la ruta de clase: se.primeKey.signserver.server.signers.MRTDSigner
5.1.1 Información general

El servidor de marca de hora generatesHTML sellos temporales y cuentan con el apoyo de las siguientes opciones:
• Conjunto de políticas aceptadas
• Conjunto de algoritmos aceptados
• Conjunto de extensiones aceptadas
• Precisión micro segundo
• milisegundos de precisión
• segundos de precisión
• cadena de certificados Incluido (No incluye Actualmente CRL)
• Ordenando
• nombre de la TSA
El firmante de fecha y hora En la actualidad no son compatibles con:

• la inclusión de CRL
• atributos firmados
• atributos no firmados
Sellos de Tiempo solicitudes se atienden a través de un servicio HTTP en la URL: http: // <nombre de
host> / Sign Server / TSA SignerId = <firmante Id> '
Si va a la ID de 1 usarse no 'signerId' parámetro hielo no especificado a continuación, como valor predeterminado. El firmante de sello de tiempo
requiere un certificado de sello de tiempo con la tecla 'sello de tiempo' uso extendido solamente.
5.1.2 Propiedades Disponibles
Las siguientes propiedades se pueden configurar con el firmante:
TIEMPO DE FUENTE = propiedad que contiene la ruta de clase a la aplicación ITimeSource thatshould ser utilizado. (Opcional,
por defecto Fuente local Hora del ordenador)
ACCEPTEDALGORITHMS = A ';' cadena separada que contiene algoritmos aceptados, puede ser nulo si no debe ser
utilizado. (OPCIONAL, muy recomendable)

07.22.06 1.0 RC1
Algoritmos soportados son: GOST3411, MD5, SHA1, SHA224, SHA256, SHA384, SHA512,
RIPEMD128, RIPEMD160, RIPEMD256
ACCEPTEDPOLICIES = A ';' cadena separada que contiene las políticas aceptadas, puede ser nulo si no debe ser utilizado.
(Opcional, recomendado)
ACCEPTEDEXTENSIONS = A ';' cadena separada que contiene extensiones aceptadas, puede ser nulo si no debe ser
utilizado. (Opcional)
DEFAULTTSAPOLICYOID = El ID de política por defecto de la autoridad de marca de tiempo (necesario, si no OID

política se especifica en la solicitud de entonces se usará este valor.)
ACCURACYMICROS = Precisión en micro segundos, sólo el formato de número decimal, sólo una de las propiedades de
precisión debe ser ajustada (opcional)
ACCURACYMILLIS = Precisión en milisegundos, Sólo formato decimal número, sólo una de las propiedades de precisión
debe estar activado (opcional)
ACCURACYSECONDS = Precisión en cuestión de segundos. Sólo formato de número decimal, sólo una de las propiedades de
precisión se debe establecer (opcional)
PEDIDO = El orden (opcional), por defecto es falso.
TSA = nombre general de la Autoridad de Sellado de Tiempo. (Opcional)
5.2 DVLM firmante

El firmante DVLM tiene la ruta de clase: se.primeKey.signserver.server.signers.MRTDSigner
El DVLM firmante realiza una operación de firma RSA en los datos entrantes. Los datos deben estar acolchados alreadyloggedin. Este firmante que
utiliza para firmar es decir, pasaportes electrónicos sobre los documentos de viaje de lectura mecánica. Las firmas se solicita a través de RMI SSL y
el primer tarjeta se requiere para su construcción. Sin equilibrador de carga se requiere para que sea redundante, esto se hace con las bibliotecas de
cliente.

No hay propiedades de configuración existe.

07.22.06 1.0 RC1
6 SignTokens disponibles
Existe dos tipos de fichas de signos, una ampliación de las teclas de software y uno en la tarjeta inteligente. Vea la sección de desarrollador para
obtener información sobre el desarrollo de apoyo a otros HSMS.
6.1 P12SignToken
El firmante P12SignToken tiene la ruta de clase:
se.primeKey.signserver.server.signertokens.P12SignToken
Una señal de emergencia usando una tienda de 12 teclas PKCS en el sistema de archivos. sólo puede contener 'una clave de firma. En un
entorno en clúster debe ser el almacén de claves en el mismo lugar en todos los nodos.
PATH almacén de claves: La ruta completa de la llave-tienda para cargar. (Obligatorio)
Contraseña del almacén: La contraseña que bloquea la clave de la tienda. Se utiliza para la activación automática.
6.2 PrimeCardHSMSignToken

Usando PrimeCardHSM es posible utilizar una tarjeta inteligente para generar firmas de 2048 bits. La tarjeta inteligente puede realizar
alrededor de una firma de un segundo.
PrimeCardHSM requiere software pcscd y los controladores de tarjetas inteligentes. Ver la documentación correspondiente sobre la instalación
de PrimeCardHSM.

defaultKey = El valor hash de la clave de firma en la tarjeta. Consulte la documentación PrimeCardHSM para
más información. (Obligatorio)
AUTHCODE = Código de autenticación para la activación automática (opcional).


07.22.06 1.0 RC1
7 Ajuste del tipo de autorización
Por defecto es la autenticación de certificado de cliente necesario para una petición de firma para ser procesados. Esto se puede cambiar
con el TipoAut propiedad.
TipoAut = noauth, establece que el servidor no requiere ningún tipo de autenticación. TipoAut = clientcert (por defecto) requiere
un certificado de todos los clientes. Los certificados deben estar en la lista de control de acceso firmantes y ser de confianza
para la distribución de Java,

es decir, importado en JAVA_HOME / jre / / seguridad / cacerts lib.
8 Desactivación de una firmante
Un firmante puede ser desactivado, lo que Esto significa que no realizará ninguna firma o pedir solicitudes incluidas en la comprobación de la Salud.
Para desactivar un firmante establece la propiedad "desactivada" a "TRUE"
9 Respuestas de archivado
Si hay una necesidad de guardar todas las respuestas generadas, a continuación, establecer el "archivo" propiedad "TRUE" y todas las respuestas
generado para dicho firmante se guardarán en la base de datos.
Las respuestas archivados más adelante pueden ser extraídos de la base de datos utilizando la interfaz CLI. Vea la sección de CLI para obtener
más información.
10 Creación e implementación del servidor de suscripción
Para construir e implementar el primer marido Sign Server surethat hormiga, Java y JBoss se ha instalado correctamente. Luego
descomprimir el paquete de servidor de suscripción y vaya al directorio en el que de casa.
Antes de empezar a hacer, asegurarse de que tiene un almacén de claves del servidor web en formato JKS (y esposo surethat el certificado del
servidor tiene el nombre de host justo en que es CN). Nombre que tomcat.jks a lo puso en un subdirectorio p12. También colocar el certificado raíz del
servidor Web en la codificación DER en el mismo directorio, lo llaman rootcert.cer
Editar el archivo signserver_build.properties. Al menos configurar la propiedad httpsserver.password. Si está utilizando otra base de datos que
HSQL construido en Jboss (recomendado para su uso en producción) y luego configurar las propiedades de base de datos.

07.22.06 1.0 RC1
A continuación, edite el archivo signserver_server.properties. Este es el archivo donde se configuran los firmantes disponibles y que se debe firmar un
uso simbólico. Por defecto es un símbolo de marca de tiempo con un signo pkcs12 token como signerId '1'.
Hacer ant deploy y luego reiniciar JBoss.
A continuación, edite los signserver_cli.properties y establecer el nombre de host. * Propiedades.
Ahora ya está listo para configurar el firmante y firmar fichas. Esto se hace por el bin \ signserver.sh setProperty <signerId> <property>
<valor> comando. Vea la sección "Administrar el servidor de suscripción 'para obtener más información sobre los comandos de la CLI
disponibles.

07.22.06 1.0 RC1
11 Administrar el servidor de sesión
El servidor de suscripción se administra mediante una interfaz CLI.
Cada firmante se identifica mediante un ID. El ID es el mismo que se especifica en las signserver_config.properties. Es posible realizar una
configuración mientras se está en producción. Todos los comandos de configuración son guardados hasta que se emite una orden de recarga y
la configuración se activa.
Hay un archivo de propiedades especiales para la interfaz CLI llamados signserver_cli.properties definir qué nodos que existe en el
clúster. Las propiedades son:
hostname.masternode = sólo debe contener 'uno de los nodos, no especificado como nodo maestro. Utilizado por las operaciones
que se ocupan de la base de datos y donde no todos los nodos del clúster debe ser contactado.
hostname.allnodes = Debe Containe todos los nodos de la agrupación, separadas por un ';'. Utilizado por los comandos
getStatus, activateSignToken y deactivateSignToken. El CLI se encuentra en bin \ signserver.sh/cmd
Obtener estado de los comandos:

Devuelve el estado del firmante dado, se dice si es símbolo señal es activa o no y la
configuración cargada 'activa'.
Obtener configuración de comandos:

Devuelve la configuración actual de uno de los firmantes. Observe thatthis configuración no podría haber sido activado aún, caso hasta que se
emite un comando de 'recarga'.
Conjunto de comandos de la propiedad:

Establece una propiedad personalizada utilizado por el firmante firmante o fichas, véase la referencia para el firmante y firma de token
para las propiedades disponibles.
Retire Comando del inmueble:

Elimina una propiedad configurado
Sube Comando Certificado:

Cuando se utiliza la actualización del certificado utilizado para firmar, solicitudes de firma
Sube Certificado de comando de la cadena:

Usado cuando se actualiza el firmante TSA Cuando se utiliza una señal de hardware del firmante. Utilizar éste en lugar de 'Cargar certificado
de comandos' en este caso.
Añadir comandos del cliente autorizado:


07.22.06 1.0 RC1
Agrega un firmantes de certificados de cliente a una lista de clientes que utilizan este aceptables firmante. especifique el
número de serie del certificado en hexadecimal y el issuerDN del certificado de cliente.
Elimina Comando certificado autorizado:

Elimina los certificados de cliente añadido.
Lista autorizada Clientes comandos:

Muestra la lista actual de clientes aceptables.
Activar la sesión de emergencia de comando:

Se utiliza para activar fichas Hårdesign, código de autenticación suele ser el PIN utilizado para desbloquear el almacén de claves en el HSM.
No se utiliza si el elemento está ajustado a la activación automática.
Desactivar sesión de emergencia de comando:

Trae una sesión de emergencia fuera de línea. No se utiliza si el elemento está ajustado a la activación automática.
Encuentra Archivo Archivo de identificador de comando:

Comando utilizado para extraer los datos archivados de la base de datos identificado por el ID de archivo. La identificación depende del
firmante, en caso de que la TSA es el número de serie de información Marca de tiempo utilizado. Los datos se almacenan con el mismo
nombre que el archivo de ID en la ruta especificada.
Archivo Buscar en el comando de solicitud de IP:

Se utiliza para extraer todos los datos archivados se solicita desde una dirección IP específica. Todos los datos se almacenan
como archivos separados con el ID de archivo como el nombre del archivo en la ruta especificada.
Archivo Buscar en el comando de solicitud de certificados:

Se utiliza para extraer todos los datos archivados, se pide a un cliente por no especificado es certificados número de serie y emisor DN.
Todos los datos se almacenan como archivos separados con el ID de archivo como el nombre del archivo en la ruta especificada.
12 Haciendo el servidor de suscripción de alta disponibilidad
12.1 acceso HTTP requiere un equilibrador de carga
firmantes basados HTTP como la TSA pueden ser agrupados utilizando un servlet chequeo devolver el estado del servidor de señalización. El servlet
de comprobación de estado se puede configurar en el archivo src / web / chequeo de salud / WEB-INF / web.xml. Con la configuración por defecto
será el servlet devolver el texto 'Allok' Al acceder a la url http: // localhost: 8080 / servidor señal / Verificación de salud / servidor Muestra de la salud . Si hay
algún problema con el servidor de señalización y el mensaje de error será tarde vuelta en su lugar.

07.22.06 1.0 RC1
El servlet de comprobación de estado también se puede utilizar para monitorear los signos erver mediante la creación de un guión que supervisa la url
periódicamente mensajes de error.
Punta, latido del corazón con ldirectord es una buena solución para un equilibrador de carga y funciona bien con el servidor de suscripción.
12.2 Configuración de MySQL Cluster
Aquí viene algunas notas sobre la configuración de un cluster MySQL y perfoming los
testscripts utilizados para configurarlo.
Gran parte de este COMO se toma de http://dev.mysql.com/tech-resources/articles/mysql-cluster-for- dos servers.html Escrito

por Alex Davies.
Un clúster mínimo consiste en tres nodos, 2 DataNodes y una estación de

administración.
Probado con MySQL 4.1.11 y 3.1.10 conector JDBC En primer lugar instalar
MySQL ( 'apt-get install mysql-server' en debian) Comience con la estación de
administración: mkdir / var / lib cd / mysql-cluster / var / lib / mysql -cluster
nos [o emacs o cualquier otro editor] CONFIG.INI insertar los
siguientes (sin BEGIN y END):

----- ---- EMPEZAR
NDBD DEFAULT]
NoOfReplicas = 2 [Mysqld
DEFAULT] [NDB_MGMD
DEFAULT] [TCP DEFAULT]
# servidor de gestión
[NDB_MGMD]
Hostname = 192.168.0.3 # la IP de este servidor
# Motores de almacenamiento
[NDBD]
Hostname = 192.168.0.1 # la IP del primer servidor
DATADIR = / var / lib / MySQL-cluster [NDBD]
Hostname = 192.168.0.2 # el IP del segundo servidor

Datadir = / var / lib / mysql-cluster
# 2 clientes de MySQL
# Yo personalmente deja en blanco para permitir cambios rápidos de los clientes MySQL;
# puede introducir los nombres de host de los dos servidores anteriores aquí. Le sugiero que haga. [Mysqld] [Mysqld]

07.22.06 1.0 RC1
-----FIN ----
Ahora, inicie el servidor managment:
ndb_mgmd
A continuación hay que configurar los DataNodes,
que /etc/my.cnf (s /etc/mysql/my.cnf en debian) Añada la
siguiente:
- - - - - COMENZAR
---- [mysqld] ndbcluster
NDB de conexión cadena = 192.168.0.3 # La IP del MANAGMENT (tercero) NDBCLUSTER SERVIDOR

default-storage-engine = [mysql_cluster]
NDB cadena de conexión = 192.168.0.3 # La IP del MANAGMENT (tercero) SERVIDOR

- - - - - FIN -----
Si se va a usar el MySQL en un clúster de JBOSS Debe finlandeses desactivar la

variable tie-dirección para la base de datos se puede conectar a la red.
# dirección de unión = 127.0.0.1
La variable de almacenamiento por defecto deben fijarse de manera JBOSS puede crear
automáticamente es tablas.
Ahora, hacemos el directorio de datos y arranque el motor de almacenamiento: mkdir / var /
lib cd / mysql-cluster / var / lib / mysql-cluster NDBD --initial
inicio /etc/rc.d/init.d/mysql.server
Nota: Se debe utilizar SOLAMENTE --initial Si usted está comenzando desde cero o ha cambiado el archivo
config.ini en la gerencia de lo contrario sólo tiene que utilizar ndbd. Hacer exactamente lo mismo para el otro
nodo.
El siguiente paso es comprobar que todo está funcionando. Esto se realiza en la estación de
administración con el comando ndbd_mgm. En el 'show' de impresión consola y obtendrá
algo como:
---- ----- BEGIN
configuración de clúster
----------------- - ---

07.22.06 1.0 RC1
[NDBD (NDB)] 2 nodo (s)

id = 2 @ 192.168.115.4 (Version: 4.1.11, NODEGROUP: 0) id = 3
@ 192.168.115.5 (Version: 4.1.11, NODEGROUP: 0, Master) [ndb_mgmd (MGM)] 1 nodo (s)
id = 1
@ 192.168.115.6 (Version: 4.1.11) [mysqld (API)] 2
nodo (s) id = 4
@ 192.168.115.4 (Version: 4.1.11) id = 5

@ 192.168.115.5 (Versión: 4.1.11)
----FIN -----
Lo que indica que todo está bien.
TIP Si experimenta problemas después de un nodo de datos MySQL bajando y se quejan de no poder
conectarse a una toma de corriente, ejecute este comando en el concole managment: borrar
definitivamente sesiones rancio
Para hacer una prueba de la setupsusing JDBC Hay dos pequeñas escritura de la prueba. En
primer lugar crear una base de datos de prueba en una mesa y 'ctest' con los siguientes comandos:
prueba de uso;
CREAR ctest TABLA (INT) también agregar
permisos en la base de datos.
GRANT ALL ON * A prueba de 'usuario' @ '<su anfitrión escritura de la prueba>' IDENTIFICADAS POR 'foo123' Para probar el
cluster Hay dos scripts de prueba pequeña prueba de hormigas:. DB que hace pruebas básicas de funcionalidad
y pruebas: dbContiously que se suma un entero cada segundo y comprueba que lo que realmente
havebeen añadió. Se da salida a los datos de las cuales usted puede test_out.txt cola para ver lo que
está pasando Cuando uno de los servidores es derribado.
13 Pruebas
Las siguientes pruebas se han hecho.
13.1 pruebas automáticas JUnit

JUnit pruebas automáticas se encuentra en el directorio " src / pruebas

07.22.06 1.0 RC1
Para ejecutar el conjunto de pruebas hacer lo siguiente:

• Establecer la variable de entorno SIGNSERVER_HOME
• Asegúrese de que el servidor de suscripción se despliega y JBoss se está ejecutando
• Hacer 'ant test: ejecutar'
13.2 El cliente de prueba

Existe un cliente de prueba construido con la distribución principal.
Sólo funciona sin requisitos de autenticación de clientes ya través de HTTP. Para ejecutar el cliente
hacer
hormiga
CD dist-cliente
java-jar timeStampClient.jar "http: // <nombre de host>: 8080 / Sign Server / TSA signerId = 1"
Continuamente se hará una solicitud por segundo.
13.3 pruebas manuales
El firmante marca de tiempo havebeen probado con el cliente OpenTSA con molestarse HTTP y HTTPS.
14 para desarrolladores
Para los firmantes personalizados DE DESARROLLO PARA EL señal de fichas de los siguientes pasos tienen que ser hechas
14.1 La interfaz ISigner

• Crear clase firmante personalizada La implementación de la interfaz se.primeKey.signserver.server.signers.ISigner. Existe
una BaseSigner que pueden heredarse el cuidado de algunas de las funcionalidades. Si el BaseSigner se hereda sólo uno
datos de diseño método () necesita ser encarnado.
Puede definir sus propias propiedades que el firmante puede utilizar para la configuración.
• Grabar el firmante de la solicitud mediante la edición del archivo signserver_server.properties y asignarle un ID.
• Asegúrese de que la clase personalizada está disponible para el servidor de aplicaciones

• Redistribuir el firmante del servidor y el firmante está listo para ser configurado y utilizado.
14.2 La interfaz de Red helado
• Un identificador de señal de costumbre debe implementar la interfaz

se.primeKey.signserver.server.signtokens.ISignToken. Ver P12SignToken para una implementación de ejemplo.
Puede definir las propiedades propias de unas fichas de signo en la misma forma que para los firmantes. Las propiedades llegan tarde a las
fichas de señal en la inicialización.
• Grabar la señal de signo a un firmante mediante la edición del archivo signserver_server.properties.

07.22.06 1.0 RC1
• Asegúrese de que la clase personalizada está disponible para el servidor de aplicaciones

• Volver a implementar el servidor firmante.
15 Referencias
Java 1.5 (o 1.4) (http://java.sun.com) Jboss-4.0.4.GA

(http://www.jboss.org) versión 1.6.5 hormiga ( http://ant.apache.org
) BouncyCastle ( http://www.bouncycastle.org )

Signserver Manual 1 0 RC1.Sv - Es

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Signserver Manual 1 0 RC1.Sv - Es

Transféré par

Droits d'auteur :

Formats disponibles

Página No. / Página No.

EJBCA Sign Server, Manual 1 (18)

07.22.06 1.0 RC1

EJBCA Sign Server

EJBCA Sign Server, Manual 2 (18)

07.22.06 1.0 RC1

2 Historial del documento

versión Fecha nombre comentario

0.1 2006-06-04 Philip Vendil La versión inicial de este documento.

1.0 RC1 2006-08-22 Philip Vendil versiones preliminares

EJBCA Sign Server, Manual 3 (18)

07.22.06 1.0 RC1

1 Introducción / Alcance .............................................. .................................................. ........................... 2

EJBCA Sign Server, Manual 4 (18)

07.22.06 1.0 RC1

3 Inicio rápido de un simple sello de tiempo de servidor

3.1 Software necesario

Java 1.5 (o 1.4) (http://java.sun.com) Jboss-4.0.4.GA

(http://www.jboss.org) versión 1.6.5 hormiga

(http://ant.apache.org ) firmar servidor-1,0-beta1 ( http://www.ejbca.org

tienda-sello-llave de la hora en formato PKCS12

3.2 Pasos de la instalación

2. Establecer las variables de entorno JAVA_HOME y JBOSS_HOME.

3. Descomprimir el paquete de servidor de suscripción y vaya a su directorio personal.

5. A continuación, signserver_build.properties editar el archivo. Al menos configurar la propiedad httpsserver.password.

7. Editar los signserver_cli.properties y establece el nombre de host. * Propiedades.

8. Utilice el servidor de suscripción a Clipper Establecer las siguientes propiedades:

(En la sección de ruta, utilice '\\' FOR '\' en el entorno de Windows.)

EJBCA Sign Server, Manual 5 (18)

07.22.06 1.0 RC1

bin \ signserver.sh recarga

9. Ejecutar la prueba a cliente ver que todo se ha acabado.

EJBCA Sign Server, Manual 6 (18)

07.22.06 1.0 RC1

seguimiento de las claves de firma (puede ser software o hardware basado).

Un servidor de suscripción puede tener múltiples firmantes para diferentes propósitos.

EJBCA Sign Server, Manual 7 (18)

07.22.06 1.0 RC1

Firmante 5,1 sello de tiempo

5.1.1 Información general

El firmante de fecha y hora En la actualidad no son compatibles con:

5.1.2 Propiedades Disponibles

Las siguientes propiedades se pueden configurar con el firmante:

EJBCA Sign Server, Manual 8 (18)

07.22.06 1.0 RC1

DEFAULTTSAPOLICYOID = El ID de política por defecto de la autoridad de marca de tiempo (necesario, si no OID

PEDIDO = El orden (opcional), por defecto es falso.

TSA = nombre general de la Autoridad de Sellado de Tiempo. (Opcional)

5.2 DVLM firmante

5.2.1 Información general

5.2.2 Propiedades Disponibles

EJBCA Sign Server, Manual 9 (18)

07.22.06 1.0 RC1

6.1.2 Propiedades Disponibles

PATH almacén de claves: La ruta completa de la llave-tienda para cargar. (Obligatorio)

6.2.1 Información general

6.2.2 Propiedades Disponibles

AUTHCODE = Código de autenticación para la activación automática (opcional).

EJBCA Sign Server, Manual 10 (18)

07.22.06 1.0 RC1

7 Ajuste del tipo de autorización

para la distribución de Java,

8 Desactivación de una firmante