Información de referencia › Guía de referencia del catálogo de dispositivos › Catálogo del sistema › Puertas de enlace › INSSLR: puerta de enlace de entrada HTTP redundante compatible con SSL.

INSSLR: puerta de enlace de entrada HTTP redundante compatible con SSL.

Ver el vídeo

Última versión: 3.1.2-1

Descripción general del funcionamiento

El dispositivo INSSLR es una puerta de enlace de 7 niveles para solicitudes de HTTP seguras. Convierte las solicitudes en solicitudes HTTP no codificadas. Esto se puede utilizar siempre que sea necesario admitir HTTP seguro en el lado del cliente pero la infraestructura de procesamiento de back-end no admita o no pueda admitir SSL, incluido lo siguiente:

• El uso de un servidor HTTP rápido y ligero que no admita SSL.
• El uso de varios servidores de back-end para mejorar el rendimiento u obtener redundancia, conectados a través de un conmutador de equilibrio de carga.
• El uso de varios servidores de back-end para funciones no relacionadas conectados a través de un conmutador de URL.
• La descarga de cifrado/descifrado SSL a un servidor independiente para mejorar el rendimiento.

Si se configura, INSSLR también es compatible con la autenticación de certificados de cliente. En caso de autenticación SSL mutua, tanto el cliente como el servidor intercambian sus certificados y las claves públicas correspondientes. El cliente se puede poner en contacto con la autoridad certificadora que emitió el certificado del servidor y confirmar que el certificado sea auténtico antes de continuar. El servidor puede hacer lo mismo.

En su configuración predeterminada, INSSLR actúa como puerta de enlace de 7 niveles para solicitudes HTTP seguras, proporcionando también un punto de entrada de cortafuegos para el tráfico de la red hacia una aplicación de CA AppLogic®, lo cual se puede configurar con una dirección IP estática accesible por Internet.

Si se configuran, se pueden usar dos dispositivos INSSLR en modo de conmutación por error para proporcionar un servicio redundante. En este caso, la dirección IP de INSSLR (configurada mediante ip_addr) se ejecuta solamente en uno de los nodos y se transfiere automáticamente al otro dispositivo INSSLR en caso de error. En todo momento habrá solamente un dispositivo INSSLR activo. Al ejecutarse en modo de conmutación por error se puede configurar INSSLR de modo que se ejecute en varios modos:

• Asimétrico: uno de los dispositivos es primario y cuando esté conectado asumirá la dirección IP y se activará. El dispositivo de respaldo se activa solamente si el nodo primario falla (o se detiene). Cuando el dispositivo primario vuelva a estar disponible, asumirá la dirección IP y se activará. El dispositivo primario es el que tiene la dirección IP más baja (comparación de cadenas), como se haya establecido en la propiedad fover_local_ip.
• Simétrico: los dos dispositivos son primarios y el dispositivo que se inicie primero asume la dirección de IP y se activa. El otro dispositivo se activa solamente si el primer dispositivo falla (o se detiene). Cuando el primer dispositivo vuelve a estar disponible, no asume automáticamente la dirección IP.

Al ejecutarse en modo redundante, INSSLR proporciona una interfaz en su terminal ctl para:

• Forzar a INSSLR a ser dispositivo primario.
• Forzar a INSSLR a ser dispositivo de respaldo.
• Comprobar el estado de INSSLR (primario/respaldo).

INSSLR constantemente controla el estado del dispositivo de back-end conectado a su terminal http. Los controles de estado realizados por INSSLR pueden incluir una comprobación de la conexión TCP sencilla o una solicitud HTTP más compleja (especificada en el límite de INSSLR). En caso de error del dispositivo conectado, INSSLR comunica un error al cuadro de mandos del grid o, si está en modo redundante y configurado para hacerlo, hace una conmutación por error al dispositivo INSSLR de respaldo.

Para ser compatible con aplicaciones que tienen que aparecer en una sola dirección IP para más de un servicio, se puede configurar INSSLR para dirigir tráfico no HTTP de forma transparente a un terminal de salida aparte. Para este tipo de conexiones, el dispositivo actúa como un enrutador de cortafuegos/NAT de capa 3.

Límite

Recursos

La memoria predeterminada para CA AppLogic® versión 2.7 se ha cambiado a 128 MB. La memoria mínima sigue siendo 64 MB.

Notas

• Cuando utilice INSSLR en el modo de conmutación por error (fover_mode no está establecido como "none"), la memoria mínima es de 100 M.
• La cantidad de memoria proporcionada a INSSLR no afecta al rendimiento. Utilice más memoria solamente para poder admitir más solicitudes simultáneas en los casos en los que los servidores de back-end se queden con las solicitudes durante períodos de tiempo demasiado largos.

Terminales

Propiedades

Propiedades de los controles de estado

Propiedades avanzadas (utilizadas en escenarios de conmutación por error)

Volúmenes

Mensajes de error

Los mensajes siguientes pueden aparecer en el archivo de registro del dispositivo o en el registro del sistema del controlador de grid cuando el dispositivo falla al iniciarse:

• failed to mount data volume
• failed to set permissions on the data share
• Samba failed to start
• NFS failed to start
• Apache failed to start

Rendimiento

Conmutación por error de aplicación

INSSLR detecta el error del otro INSSLR en unos 10 segundos. Tarda unos 10 segundos más en realizar la conmutación por error a la otra aplicación. El tiempo total desde que se produce el primer error de la aplicación hasta que la otra aplicación asume el tráfico es de unos 20 segundos.

Tasa de solicitudes

INSSLR enruta no menos de 3.000 transacciones (parejas de solicitud/respuesta) por segundo, según el tamaño de los documentos y el ancho de banda de red disponible.

Rendimiento de los datos

INSSLR enruta no menos de 7 MBytes/segundo, según el tamaño de los documentos y el ancho de banda de red disponible.

Conexiones simultáneas

Con la memoria predeterminada INSSLR es compatible con no menos de 500 solicitudes pendientes simultáneas. (Una solicitud pendiente es una conexión TCP abierta del cliente, donde hay una o varias solicitudes HTTP sin completar en curso). El número máximo de conexiones simultáneas depende de la memoria libre disponible. Cada 16 MB más de memoria aumenta por 500 el número de transacciones http simultáneas. Por ejemplo, si ejecuta en el modo redundante y desea poder servir 2.000 conexiones simultáneas, necesita 100 M + 3*= 148 M (la memoria mínima cuando se ejecuta en el modo redundante es de 100 M).

Notificaciones

Cuando se ejecuta en el modo redundante (fover_mode no está definido como "none"), INSSLR activa las notificaciones siempre que pase a ser activo/pasivo. Esto se hace durante el inicio del nodo activo o cuando se produce una conmutación por error (cada nodo envía una notificación de que pasó a ser activo/pasivo).

INSSLR envía dos notificaciones:

• Una notificación al cuadro de mandos del grid: INSSLR appliance APP_NAME:COMP_NAME <acquired|gave up> resource ip_addr
• Una solicitud http mediante el terminal nfy. Depende del extremo de recepción el tomar las medidas necesarias según la notificación. La URL solicitada es:

  http://nfy/fover_nfy_prefixfover_mode=fover_mode&state=<start|stop>&ip_addr=ip_addr&fover_local_ip=fover_local_ip&fover_remote_ip=fover_remote_ip&fover_netmask=fover_netmask

  Se puede utilizar fover_nfy_prefix para cambiar la ubicación del script remoto que se llama o para agregar más parámetros. Ejemplos de valores de fover_nfy_prefix: /path/to/script.php?, /path/to/script.php?username=user&password=pass&.

Importante:

• Cuando utilice fover_nfy_prefix con un valor distinto al predeterminado, asegúrese de que termina con el signo ? si fover_nfy_prefix es sólo la ruta al script o con el signo & si fover_nfy_prefix incluye más parámetros.
• Si un nodo pasa a estar no disponible puede que sea capaz de enviar una notificación de que ha pasado a ser pasivo y sólo el nodo que pasa a estar activo envía la notificación.
• El tiempo de espera para la solicitud http es de 5 segundos para que la conmutación por error no se ralentice.

Control de estado

INSSLR ejecuta un cronjob cada minuto que comprueba:

• Si el espacio libre del volumen de datos es inferior al 20 %.
• Si el daemon de rsync se está ejecutando (solamente si se configura como secundario).
• Si el proceso de replicación está en ejecución (solamente si se configura como principal). En caso contrario, se reinicia el proceso de replicación.

Si se cumplen cualquiera de las condiciones anteriores, se envía un mensaje de error al cuadro de mandos del grid. Si más de una prueba es incorrecta, se publicará un mensaje en el cuadro de mandos del grid que resuma todos los errores. Cada error se enviará solamente una vez cada hora al cuadro de mandos del grid. No se comunica ningún error en los primeros 5 minutos después del inicio del dispositivo (para evitar falsas alarmas si el otro nodo de la replicación no se ha iniciado).

Certificados del servidor

Para utilizar SSL se necesita tanto el certificado firmado como la clave privada con la que éste se encriptó. La clave y el certificado deberían estar en formato PEM y colocarse en un único archivo especificado por la propiedad cert_file.

Esta sección contiene los siguientes temas:

Generación de certificados de servidor

Uso de certificados de servidor

Uso de certificados de servidor apache+mod_ssl existentes

Generación de certificados de servidor

CA AppLogic® le permite generar certificados de servidor.

Generación de certificados de servidor

1. Genere una clave privada mediante el comando siguiente:

   openssl genrsa -out privkey.pem 2048 
   

   Para generar una clave protegida por contraseña, utilice lo siguiente (para utilizar la clave con INSSLR necesita una clave sin contraseña; si crea una clave protegida por contraseña necesitará eliminar la contraseña antes de usarla en INSSLR).

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. A continuación, necesita un certificado. Tiene dos opciones: crear una solicitud de certificado y hacer que la firme una fuente de CA de confianza (sujeto a un tarifa), o crear un certificado autofirmado para fines de prueba (en este caso los exploradores que soliciten su sitio emitirán advertencias que indicarán que el certificado no está firmado por una fuente CA de confianza).

   Para generar una solicitud de certificado, ejecute lo siguiente:

   openssl req -new -key privkey.pem -out server.csr 
   

   Después de enviar el archivo .csr a la autoridad certificadora de confianza, se le devolverá un certificado firmado (archivo .crt) que puede utilizar.

3. Para generar un certificado autofirmado, ejecute lo siguiente:

   openssl req -new -x509 -key privkey.pem -out server.crt -days 1095
   

Uso de certificados de servidor

Ya puede colocar el certificado y la clave en un archivo y utilizarlo en INSSLR:

cat privkey.pem  server.crt > server.pem 

Si su clave está protegida mediante contraseña, ésta se puede eliminar ejecutando lo siguiente:

openssl rsa -in key_with_pass.pem -out privkey.pem

Uso de certificados de servidor apache+mod_ssl existentes

Si tiene un certificado existente que usa en Apache, puede utilizarlo también en INSSLR. Asegúrese de que la clave no está protegida con contraseña (consulte más arriba) y coloque la clave privada y el certificado en un archivo en ese orden.

Ejemplo:

cat privkey.pem  server.csr > server.pem 

Si está usando un certificado encadenado, debería incluir también el certificado intermedio proporcionado por el emisor. Coloque la clave privada, el certificado y el certificado intermedio en un archivo en ese orden.

Ejemplo:

cat privkey.pem server.csr sf_issuing.crt > server.pem 

Importante: La clave de firma del servidor es la prueba de identidad de su sitio Web. También es vulnerable, porque no está encriptada por contraseña (para que el dispositivo la pueda leer sin ayuda). Tome las medidas necesarias para proteger el archivo de clave cuando lo instale en el volumen de datos. No utilice el mismo volumen de datos para otros fines y no lo haga visible para un servidor Web, por ejemplo, para los datos del host a los que se aceden mediante Web (páginas HTML, scripts, etc.).

Certificados del cliente

Los ejemplos siguientes describen cómo puede crear su propia autoridad certificadora y utilizarla para firmar sus propios certificados mediante OpenSSL. Esto se probó mediante OpenSSL 0.9.8b, la misma versión que se instaló en INSSLR.

Esta sección contiene los siguientes temas:

Creación de una autoridad certificadora

Creación de certificados de cliente firmados por la autoridad certificadora

Creación de archivos de la lista de CA utilizadas por INSSLR

Encabezados de los certificados del cliente

Creación de una autoridad certificadora

Si ya tiene una autoridad certificadora propia que se utiliza para crear certificados autofirmados, puede omitir este paso y utilizar esa autoridad certificadora. Al crear los instrumentos de la autoridad de confianza para la aplicación, es importante que el entorno sea seguro.

Creación de una autoridad certificadora

1. En un sistema de host seguro, cree un directorio de trabajo y un directorio privado dentro del directorio que funciona mediante los comandos siguientes:

   mkdir CA 
   mkdir CA/private 
   

2. Cree una clave RSA protegida con contraseña para la autoridad certificadora que tenga una longitud de 2048 bits:

   openssl genrsa -des3 -out CA/private/CA_key.pem 2048 
   

• Con la clave privada, cree un de certificado de clave pública para la autoridad certificadora:

  openssl req -new -key CA/private/CA_key.pem -x509 -days 365 -out CA/CA_cert.pem 
  

Importante: La clave privada para la autoridad certificadora constituye la base de confianza de la aplicación, no la pierda ni la proporcione a otras partes.

Creación de certificados de cliente firmados por la autoridad certificadora

CA AppLogic® le permite crear certificados de cliente firmados por la autoridad certificadora.

Creación de certificados de cliente firmados por la autoridad certificadora

1. Genere una clave privada RSA (para crear una clave protegida con contraseña, use el conmutador -des3):

   openssl genrsa -out clientA_privkey.pem 2048 
   

2. Genere una solicitud de firma de certificado (CSR) de la clave privada:

   openssl req -new -key clientA_privkey.pem -out clientA_request.csr 
   

3. Firme el certificado contenido en CSR mediante el certificado generado para CA:

   openssl x509 -req -days 365 -in clientA_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAcreateserial -out clientA.cer 
   

Tenga en cuenta lo siguiente:

• El conmutador -CAcreateserial permite asignar números de serie únicos a certificados emitidos. Dado que este es el primer certificado que emite la autoridad certificadora, el archivo CA/CA_cert.srl se crea para realizar un seguimiento de los números de serie. Si se crean subsiguientes certificados de cliente, el conmutador -CAserial se usa en lugar del conmutador -CAcreateserial. Por ejemplo:

  openssl genrsa -out clientB_privkey.pem 2048 
  openssl req -new -key clientB_privkey.pem -out clientB_request.csr 
  openssl x509 -req -days 365 -in clientB_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAserial CA/CA_cert.srl -out clientB.cer 
  

• Para crear un solo archivo con formato PEM que incluya tanto el certificado de cliente como de clave, ejecute lo siguiente:

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Para crear el archivo equivalente en formato pkcs12 (que lo pueden utilizar la mayoría de los exploradores):

  openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12
  

Creación de archivos de la lista de CA utilizadas por INSSLR

Revocación de certificados de cliente firmados por CA

Para revocar certificados de cliente firmados por CA, ejecute lo siguiente:

• openssl ca -config openssl.conf -revoke clientB.cer -crl_reason keyCompromise

Donde un "openssl.conf" de ejemplo se muestra a continuación y el parámetro "crl_reason" es uno de los siguientes: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold o removeFromCRL. El valor de "reason" no distingue entre mayúsculas y minúsculas.

Para volver a generar la lista de revocación de certificados (CRL), ejecute lo siguiente:

• openssl ca -config openssl.conf -gencrl -out CA/crl.pem

En este ejemplo "crl.pem" es el archivo que se debería proporcionar a INSSLR como la propiedad "cert_revocation_list".

El archivo de configuración de muestra que se utiliza en el anterior ejemplo es:

      ####################################################################
      [ ca ]
      default_ca      = CA_default            # The default ca section

      ####################################################################
      [ CA_default ]

      dir             = ./CA                  # Where everything is kept
      certs           = $dir/certs            # Where the issued certs are kept
      crl_dir         = $dir/crl              # Where the issued crl are kept
      database        = $dir/index.txt        # database index file.
      #unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
      new_certs_dir   = $dir/newcerts         # default place for new certs.

      certificate     = $dir/cacert.pem       # The CA certificate
      serial          = $dir/serial           # The current serial number
      crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
      crl             = $dir/crl.pem          # The current CRL
      private_key     = $dir/private/cakey.pem# The private key
      RANDFILE        = $dir/private/.rand    # private random number file

      default_days    = 365                   # how long to certify for
      default_crl_days= 30                    # how long before next CRL
      default_md      = sha1                  # which md to use.
      preserve        = no                    # keep passed DN ordering

      policy          = policy_anything

      [ policy_anything ]
      countryName             = optional
      stateOrProvinceName     = optional
      localityName            = optional
      organizationName        = optional
      organizationalUnitName  = optional
      commonName              = supplied
      emailAddress            = optional

Creación de archivos de la lista de autoridades certificadoras utilizadas por INSSLR

CA AppLogic® le permite crear los archivos de la lista de autoridades certificadoras utilizadas por INSSLR

Para crear el archivo identificado por la propiedad ca_list_client, lleve a cabo los pasos siguientes:

1. Acceda al siguiente archivo:

   cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem 
   

2. Coloque este archivo en el volumen de clave o en el volumen montado en nfs mediante el terminal fs.
3. Si se desea, también se puede crear el certificado de servidor de INSSLR (por ejemplo, server.pem) de la misma forma que los certificados de cliente y firmado, de igual modo, por la autoridad certificadora creada. No utilice una contraseña para este certificado.
4. Una vez que server.pem y ca_list_client.pem están en su lugar, la autenticación del certificado del cliente se puede probar de la siguiente manera:
   • Para hacer la comprobación desde un explorador, importe un certificado de cliente con formato pkcs12 en Firefox mediante Herramientas, Opciones, Ver certificados, Sus certificados, Importar. Apunte el explorador a la dirección IP de INSSLR.
   • Para probar el protocolo de enlace de SSL desde un host remoto, ejecute lo siguiente:

     openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state 
     

Encabezados de los certificados del cliente

Si un cliente se conecta a INSSLR mediante HTTPS, y si presenta un certificado de cliente, INSSLR agrega los encabezados siguientes a la solicitud que suministra al servidor de back-end:

• X-SSL-Subject: proporciona información sobre el propietario del certificado.
• X-SSL-Issuer: proporciona información sobre el emisor del certificado (autoridad certificadora).
• X-SSL-serial: indica el número de serie del certificado (decimal).
• X-SSL-cipher: indica el encriptado que se está utilizando.
• X-SSL-certificate: indica el certificado completo del cliente (multilínea en formato PEM).

La aplicación tiene la responsabilidad de utilizar o no estos encabezados. INSSLR transmite simplemente esta información sin verificarla de ninguna manera (excepto la corrección del encriptado y la firma).

Aplicaciones Web

Para proporcionar acceso de http(s) a su aplicación, conecte el terminal http directamente al dispositivo de WEB.

Si necesita una aplicación Web escalable, enlace el terminal http a un dispositivo HLB.

Configuración para aplicaciones Web

Los ejemplos de configuración indican solamente las propiedades establecidas a los valores no predeterminados y no se muestra la configuración de red (dirección ip, máscara de red, puerta de enlace).

Aplicaciones Web con servicios adicionales

Si tiene más servicios además de http en su aplicación, puede utilizar INSSLR para pasar el tráfico http al terminal http y usar el terminal aux para otros servicios.

Aplicaciones Web con más de un servicio

Si tiene varios servicios tcp/udp y http, puede utilizar INSSLR para transferir el tráfico http al terminal http y utilizar aux para abastecer el resto del tráfico PS8, que suministra el tráfico deseado a los servidores de back-end.

Aplicaciones Web redundantes

Si necesita proporcionar una aplicación Web redundante, puede copiar la aplicación y utilizar INSSLR para proporcionar capacidades de conmutación por error a la dirección IP externa.

Aplicación Web de copia de seguridad

Si sólo desea una aplicación de copia de seguridad que notificará a los usuarios el tiempo de inactividad, puede utilizar INSSLR para generar una aplicación de copia de seguridad que necesita unos recursos mínimos.

Dispositivos en uso:

• user: puerta de enlace de entrada para solicitudes de usuario.
• web: servidor Web que muestra un mensaje de mantenimiento.

INSSLR en la aplicación primaria:

INSSLR en la aplicación de copia de seguridad:

Aplicación Web redundante (una sola aplicación)

Si se desea que su aplicación se ejecute en el modo redundante sin tener que crear una nueva aplicación, puede doblar los dispositivos de esta y ejecutarlos en modo redundante. Como esto implica el uso (al menos) de dos servidores Web y dos dispositivos de base de datos, en el modo normal se usan todos (lo que proporciona escalabilidad), pero cada uno de ellos puede servir sólo a la aplicación en caso de que se produzca un error en el otro dispositivo. Si necesita más escalabilidad, puede agregar más dispositivos Web y base de datos. En este ejemplo la mitad de los dispositivos (in1, sw1, web1, db1) se ejecutan en un grupo de conmutación por error y el resto (in2, sw2, web2, db2) están en otro grupo de conmutación por error, de forma que la aplicación puede sobrevivir en caso de que se produzca un error en el servidor. Esta aplicación proporciona redundancia a un coste muy bajo, puesto que todos los dispositivos (excepto en el caso de un dispositivo INSSLR y otro HALB, que requieren recursos muy bajos) están en estado activo y no se consume ningún recurso para una aplicación de copia de seguridad que se ejecuta solamente si se produce un error en la primaria.

in1

in2

db1

db2

Aplicación Web redundante (dos aplicaciones idénticas)

Se pueden ejecutar dos aplicaciones idénticas en el mismo grid (pero en servidores separados para que el error de un servidor sólo afecte a una de las aplicaciones) o en grids diferentes siempre que la dirección IP que utilice sea accesible desde los dos grids. El siguiente ejemplo muestra una aplicación que usa un dispositivo de base de datos que también se está ejecutando en modo redundante, para que, en caso de error de una aplicación, la otra aplicación pueda tomar el control sin que se produzcan pérdida de datos.

Dispositivos en uso:

• in1: puerta de enlace de entrada redundante para solicitudes de usuario.
• admin: puerta de enlace de entrada para acceso a los archivos de registro.
• sw: vuelva a dirigir el puerto 8080 desde admin hasta ui en db.
• repl_in: entrada para que la aplicación remota se conecte al dispositivo db para replicar la base de datos.
• web_lb: equilibrador de carga Web para solicitudes de usuario.
• web1, web2: servidores Web con contenido activo (por ejemplo, scripts de CGI).
• db: MYSQLR64 se configura para ser tanto principal como secundario al mismo tiempo.
• content: almacenamiento para archivos de registro de errores de base de datos, contenido Web y registros Web.
• logs: almacenamiento para archivos de registro de errores de base de datos.
• repl_out: puerta de enlace de salida para que el dispositivo db se conecte a la aplicación remota para replicar la base de datos.
• mon: dispositivo MON.

La solicitud del cliente llega a la puerta de enlace in1. La puerta de enlace reenvía las solicitudes al equilibrador de carga web_lb, el cual las dirige a uno de los servidores Web: web1 o web2. Los servidores Web acceden a la base de datos db. El dispositivo db se conecta a la aplicación remota (que es una copia idéntica, la única diferencia es la configuración de server_id de db y de red) para replicar la base de datos. La aplicación remota se conecta al dispositivo db mediante la puerta de enlace repl_in que se configura para permitir solamente la conexión de la puerta de enlace repl_out de la aplicación remota. Los dispositivos db de las dos aplicaciones se están ejecutando en la configuración principal-principal, así que siempre tienen datos idénticos.

Configuración de una propiedad de ejemplo (las propiedades que no se especifican deberían dejarse con sus valores predeterminados):

El acceso Web a db está disponible mediante la puerta de enlace admin en el puerto 8080.

in1

db

Importante: Solamente una de las aplicaciones está activa en todo momento, la otra se está ejecutando sólo para conmutación por error y se utiliza cuando la aplicación activa produce un error.

Notas

HTTP es compatible con INSSLR 1.0 y HTTP 1.1, pero si el cliente se identifica así mismo como MSIE, se desactiva la compatibilidad con HTTP 1.1 para esa conexión (para evitar errores en algunas versiones de MSIE).

Si el cliente no es MSIE, INSSLR es compatible con HTTP 1.1 para el cliente (incluidas varias solicitudes por capacidad de sesión TCP), aunque el servidor de back-end solamente sea compatible con HTTP 1.0.

INSSLR admite una sola IP externa y, por lo tanto, solamente se puede utilizar un solo certificado SSL.

El dispositivo incluye software de código fuente y software de terceros.

INSSLR utiliza los siguientes paquetes de código abierto o de terceros además de los paquetes de código abierto o de terceros que utiliza su clase base LUX6.