Buscar este blog

miércoles, 12 de noviembre de 2014

Client denied by server configuration: /usr/share/phpmyadmin - You don't have permission to access /phpmyadmin on this server

Al acceder a http://xxxxx/phpmyadmin/ se obtiene el siguiente error:
You don't have permission to access /phpmyadmin on this server.

Consultando los logs de Apache se muestra el siguiente mensaje;
client denied by server configuration: /usr/share/phpmyadmin

Esto me ha ocurrido durante la instalación en Centos7, siguiendo el tutorial de su wiki 

Solución
(Visto en el siguiente foro http://askubuntu.com/questions/483297/why-do-i-always-get-a-403-error-with-phpmyadmin)

Lo más probable es que ya se hayan revisado los millones de foros y blogs indicando como solucionar este error y la solución que proponían era la siguiente cambiar el fichero /etc/httpd/conf.d/phpmyadmin.conf de la siguiente forma (o en cualquiera de sus múltiples variantes con el allow):

<Directory "/usr/share/phpmyadmin">
  Order allow,deny
  Allow from all
</Directory>


Pero si se está usando apache 2.4.x la verdadera solución es la siguiente:


<Directory "/usr/share/phpmyadmin">
  Require all granted
</Directory>

Hay que usar Require all granted

Biztalk Terminating Instances running on Isolated Host - Forzar a terminar instancias activas en Isolated Host

Objetivo
Terminar todas las instancias activas que se han quedado suspendidas.
Se tienen una serie de instancias asociadadas a un puerto que se han quedado suspendicas y que no pueden ser terminadas. Se aplicará la solución más fuerte parando todo e intentándolo progresivamente.





Solución
Se indican una serie de pasos. En cada paso, intentar terminar las instancias. Si no funciona, pasar al siguiente.

1 - Parar todas las hosts instances
Para ello, desde la consola de administración de biztalk, se navega a Biztalk Server Administration > BizTalk Group > Platform Settings > Hosts Instances.
Una vez ahí, se selecionan todas y se paran.



2 - Parar todas las aplicaciones
Para ello, desde la consola de administración de biztalk, se navega a Biztalk Server Administration > BizTalk Group > Applications.
Una vez ahí, se selecionan todas y se paran.


3 - Parar IIS
Dado que el problema está en los isolated adapter, se prueba a parar los Internet Information Services de Windows.

Para ello, desde el menú de inicio se abre el IIS Manager y se para toda la conexión.



4 - Borrar la aplicación que contiene la instancias
A medida que aumenta la despesperación, incrementamos la contundencia de nuestras acciones.

Desde la consola de administración de biztalk navega a Biztalk Server Administration > BizTalk Group > Applications.
Una vez ahí se selecciona la aplicación propietaria y se borra.

Antes de borrarla se puede exportar como MSI, para recuperarla posteriormente.

Si esto no funciona, ahora las instancias tendrá de nombre <Name is not available>.
Parda la estamos liando.



5 - Biztalk Terminator
Se escala el conflicto y se usa la herramienta Biztalk Terminator.
Aquí la descripción oficinal
The BizTalk Terminator tool allows the user to easily address common BizTalk issues via SQL, WMI, and PowerShell based tasks provided by the BizTalk team. Additional functionality includes the ability to suspend, resume, and terminate in bulk by date range, make performance tuning changes, and integrate with the MessageBox Viewer utility.

Este es un blog en el que se cuentan más cosas de la herramienta.

Una vez descargada y descomprimida basta con ejecutar el .exe.



Para que no haya problemas, mejor ejecutarlo con la opción de administrador.

Los datos a configurar son:
  • Nombre del servidor de base de datos. Es el SQLServer en el que están alojadas las bases de datos de administración de biztalk. Es el parámetro de conexión que se introduce desde el Management Studio.
  • Nombre de la base de datos de biztalk. 
También hay que marcar todos los checks confirmando que se han hecho todos esos pasos. No hay garantías de que destrocemos algo, así que lo primero es hacer el backup de las bases de datos.


Una vez conectado, se pulsa en Manage. Esto recarga el combo de la parte superior, y se selecciona Suspend Instances.
En la pestaña de parameters, hay que seleccionar tres valores:
  • Service Class: Isolated Adapter
  • Service Status: Active
  • Host Name: El que corresponda (en este caso es probable que sea BizTalkServerIsolatedHost)


También se puede probar con Delete. En el combo superior seleccionar Terminate Instances.
Los parámetros a introducir son los mismos que en el caso anterior.


Si todavía siguen apareciendo las instancias indeseadas en biztalk, la siguiente opción es Delete.
En este caso se pueden seleccionar dos opciones, Terminate Single Instance (Hard Termination) / Terminate Multiple Instances (Hard Termination).

En la opción single se pedirá el ID de la instancia a borrar. Este parámetro se puede obtener viendo las propiedades de las instancias activas, desde la consola de biztalk.



En la opción multiple habrá que indicar:
  • Host Name: BizTalkServerIsolatedHost
  • Service Class: Isolated Adapter
  • Status: Active
Nota, esta opción no funciona bien, así que mejor usar la single.

6- Más cosas

También he visto en algún blog que indican cómo ejecutar las querys directamente contra base de datos, en vez de usar esta herramienta.

Stop all BizTalk processes.
Open Group Hub, review these active instances and note the Service Instance ID and the Service Type ID. Run the following query against the BizTalkMsgBoxDb database: 

DECLARE @out INT
BEGIN TRANSACTION
exec dbo.int_AdminTerminateInstance_BizTalkServerApplication '53c209de-64d6-418f-96b0-37372013793f', '37e93c3d-cf20-0dc1-b6f4-720ad96fda4d' ,@out
COMMIT

Where BizTalkServerApplication is the HOST name, "53c209de-64d6-418f-96b0-37372013793f" is the Service Instance ID and
"37e93c3d-cf20-0dc1-b6f4-720ad96fda4d" is the Service Type ID listed in Group Hub.
You can also capture a BizTalk trace, filter on the instance ID and see if the same msgID is being retried. 

Ojo, esto no lo  he probado.

Éxito!!





martes, 11 de noviembre de 2014

SoapUI mock script - return request pararm as response

Objetivo

Dado un servicio mock, se quiere componer la respuesta en base al os parámetros de entrada. Para ello se empleará un script.

Request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:GESTIONARTASAS>
         <XMLREQUEST xmlns="">Datos de la petición</XMLREQUEST>
      </tem:GESTIONARTASAS>
   </soapenv:Body>
</soapenv:Envelope>


Response:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:GESTIONARTASASResponse>
         <XMLRESULT>${respuesta}</XMLRESULT>
      </tem:GESTIONARTASASResponse>
   </soapenv:Body>
</soapenv:Envelope>


Script:


def request = new XmlSlurper().parseText(mockRequest.requestContent)
context.respuesta = request.Body.GESTIONARTASAS.XMLREQUEST.toString()


SoapUI HTTPS Mock - java.net.BindException: Addres already in use: bind

Objetivo

Se trata de crear un servicio web mock con SoapUI, pero que responda también por HTTPS.
Se trata de corregir el error java.net.BindException: Addres already in use: bind

Nota:
Ya hay un tutorial en la página oficial de soapui, pero no explica bien la forma de acceder al servicio una vez creado. Se puede consultar aquí.

Solución

En esta prueba se empleó SoapUI 4.5.2, pero también está probado con 4.6.

Lo normal es partir de un servicio existente y luego crear su mock. Finalmente hay que configurar el HTTPS.

Para esta prueba se empleará el servicio http://www.webservicex.net/globalweather.asmx?WSDL



A partir de ahí podemos hacer peticiones al servicio real.


Luego se crean los mocks de las operaciones del servicio que queramos.






En este momento, y una vez lanzado el mock, cualquier petición que se haga a http://localhost:8088/mockGlobalWeatherSoap será atendida por dicho mock.
Se puede consultar el WSDL en el navegador con http://localhost:8088/mockGlobalWeatherSoap?wsdl.

Ahora hay que configurar el SSL. Para ello se necesitan dos keystores:

  1. IdentityKeyStore: Keystore con los datos de identidad del servidor. 
  2. TrustStore: Keystore con los certificados de confianza del servidor.

El IdentityKeyStore identifica al servidor. Tendrá su clave pública y privada, de modo que los clientes pueda consultar la pública cuando se conectan a él.

La forma más rápida de crearlo es con keystore explorer.
Basta con crear un archivo de tipo JKS y dentro de él usar la opción de Generate Key Pair. Durante el proceso se pedirán que se establezcan las contraseñas del certificado y del keystore.

El TrustStore contiene la lista de certificados, únicamente sus claves públicas, en los que confiará el servidor. En este caso no es necesario incluir ninguna, porque el cliente no necesitará certificado.
Al igual que en el caso anterior, el keystore también va a solicitar una contraseña de acceso.


Teniendo esto, ya se pueden configurar los parámetros de SSL en SoapUI.
Desde la opción de preferencias se navega a SSL Settings y se cubren los datos necesarios.



Aquí hay que tener en cuenta lo siguiente:
  • Sólo estamos cubriendo los datos del keystore para los mocks. SoapUI permite tener dos diferenciados.
  • Se indica un puerto para los mocks, pero no será con el que se acceda al servicio. Luego se verá.
  • No se solicita autenticación de cliente, de ahí que no haga falta meter certificados en el trustStore.

Una vez configurado todo hay que reniciar el SoapUI para que coja las nuevas preferencias!!

Después de reiniciar y haber arrancado el mock, se puede acceder a la siguiente URL por https:
https://localhost:8443/mockGlobalWeatherSoap?wsdl

Ojo, el mock dijimos que iba ir en el puerto 8088, pero aquí estamos entrando por el 8443 que es el del https. Esto es un poco raro y poco intiutivo, y la primera vez puedes perder bastante tiempo hasta descubrirlo. Además, no se indica demasiado en los foros.



troubleshooting 

java.net.BindException: Addres already in use: bind

Este error se produce cuando se configura el mock para que emplee el mismo puerto que el HTTPS.
Al configurar todo, lo más lógico es pensar que el mock se lanzará en el puerto del HTTPS, pero así entra en conflicto con éste porque se intenta abrir dos veces.
Hay que dejar el puerto del mock distinto al otro y entrar por HTTPS en el que corresponda.







domingo, 9 de noviembre de 2014

Apache certificates - Self signed certificates

Introducción

En muchas ocasiones, delante del servidor de aplicaciones se suele situar un servidor Apache que actúe como Proxy y controle la seguridad de acceso a la red interna. Será también el encargado de manejar las conexiones HTTPS autenticando al usuario mediante certificado digital.
El problema surge cuando, en la fase de desarrollo, no se dispone de un certificado digital reconocido por alguna Autoridad de Certificación (CA) Oficial, y hay que crear una de pruebas con la que firmar nuestros propios certificados.
A continuación se describirá el procedimiento para configurar el HTTPS de apache, así como para crear una CA de pruebas y firmar certificados con ella.


Solución

Trabajando en un entorno Windows, se descargará el la versión openssl httpd-2.2.25-win32-x86-openssl-0.9.8y.msi (http://apache.rediris.es//httpd/binaries/win32/) que ya contiene todos los componentes necesarios, sin necesidad de añadir módulos adicionales.
También se emplearán los siguientes programas:
  • KeyStoreExplorer.
    Herramienta gráfica para el manejo de certificados y keystores.
  • OpenSSL.
    Herramienta por línea de comandos para la gestión de parámetros relacionados con el SSL.
    Para descargarlo, hay que ir al menú de "related" de la página principal, y pulsar sobre el enlace de OpenSSL for Windows.
    De ahí redirige a otra página con la lista completa de opciones. En la tabla de descargas, elegir la primera opción: Win32 OpenSSL v1.0.1i Light.
    Se instalará como un programa normal y se registrará en el path del sistema, con lo que se podrá ejecutar el comando openssl desde cualquier ventana MS-DOS

Configuración del SSL de apache
Para poder acceder con certificado digital, el servidor será el encargado de pedir el certificado del cliente (two ways SSL), validarlo y enviárselo al servidor de aplicaciones donde se podrá llevar a cabo la fase de autorización en base a los datos contrastados del usuario (generalmente encapsulado dentro de un parámetro de la request).
Para realizar estas tareas se necesita lo siguiente:
  • Un certificado de servidor:
    • Clave privada.
    • Clave pública.
  • Una lista de autoridades de certificación en el servidor.
  • Añadir la configuración necesaria.

1 - Certificado de servidor
Se necesita un certificado para identificar al servidor, separando por un lado su clave de firma y por otro la parte pública del certificado. Para generalo se pueden seguir los siguientes pasos, empleando KeyStoreExplorer (También se pude hacer con OpenSSL):
  • Crear nuevo keystor
  • Generar nuevo par de claves
    • Rellenar la información de identificación
  • Exportar la clave privada (Server.key)
 
  • Exportar el certificado en formato PEM (Server.pem)


2  Lista de autoridades de certificación en el servidor
En el punto anterior configuramos la identidad del servidor. Ahora se añade la lista de CAs que usará para validar los certificados de los clientes. Cuando tenga que autenticar a un cliente, leerá el certificado del navegador y comprobará si está firmado por una de las CAs en las que confía, para aceptarlo o rechazarlo.
La lista de CAs que siempre deberá tener son:
  • Certificado raíz de la FNMT
  • Certificado raíz de la policía.
    • Se descargan tanto el raíz como las tres subordinadas.
  • Otras CAs de las que se disponga
  • CA propia para confiar en nuestros propios certificados

2.1    CAs oficiales
Una vez se descargan los certificados, para obtener su formato PEM se puede usar el keyStoreExplorer, añadiéndolos a un keystore y luego exportándolos como se hizo con el certificado de servidor, o directamente usando el editor de certificados de windows.
Al final obtenemos los archivos en formato .cer, que se pueden abrir directamente con un editor de texto y comprobar que es el formato PEM codificado en base 64.
2.2    Otras CAs de las que se disponga
También se pueden añadir otras CAS que hayan firmado certificados de pruebas de los que ya se dispongan.
En este caso, basta con abrir el certificado en formato p12 o pfx con el KeyStoreExplorer y seleccionar la CA (es el primer certificado de la jerarquía). Luego se copia su representación PEM, que será la propia CA que nos interesa.
2.3    CA propia para firmar certificados
Para crear una CA se usará el programa OPENSSL para windows.
Los primero que hay que hacer es crear las claves de la entidad certificadora, que será la que genere el resto de certificados. Se ejecuta la siguiente instrucción:


openssl req -x509 -newkey rsa:2048 -keyout cakey.pem -days 3650 -out cacert.pem

Lo que significa que estamos creando una nueva entidad que generará certificados X509 con algoritmo de encriptación rsa de 2048 bytes. Generará la clave privada de la entidad en el fichero cakey.pem y la clave publica en el cacert.pem.
El parámetro -days con 3650 indica que la entidad certificadora no expirará en 10 años.
Nos pedirá una contraseña para nuestra entidad certificadora, que es muy importante no perder. Nos pedirá también una serie de datos (País, Nombre de Empresa…), que nos identifica como entidad certificadora.
2.4   Poniéndolo todo en conjunto
En este punto ya tenemos:
  • Clave de servidor: Server.key
  • Certificado de servidor: Server.pem
  • Ficheros sueltos de CAs de policía y FNMT
  • Ficheros sueltos de otras CAs de certificados.
  • Fichero de nuestra propia CA: cacert.pem
Las CAs deben estar en un único fichero, así que se crea uno nuevo (cas.pem) y se concatena en éste el contenido de todos los anteriores, copiando y pegando. Al final quedará algo del estilo:

-----BEGIN CERTIFICATE-----
MIIC+TCCAmKgAwIBAgIENvEbGTANBgkqhkiG9w0BAQUFADA2MQswCQYDVQQGEwJF
...
LwVMZGACokIeb4ZoZVUO2ENv8pExPqNHPCgFr0W2nSJMJntLfVsV+RlG3whd
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFvzCCA6egAwIBAgIQAMUmyW4QlO1DT/e1+2eflDANBgkqhkiG9w0BAQsFADBd
....
Rua2628QZv5yKZL45hMDN4MviTN3QnzB5XillEH4avjfG9Q=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
....

Estos tres ficheros se meten en el directorio \ssl.crt dentro del directorio de configuración de Apache.
En el directorio de configuración de Apache, se crea un fichero ssl.conf que, haciendo uso de estos tres fichero, configurará el SSL del servidor. También se indican una serie de parámetros sobre los protocolos aceptados y demás opciones.

#=================================================
# SSL/TLS para los vhosts
# =================================================
SSLEngine On

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:!EXP:!eNULL:!aNULL:!LOW

SSLCertificateFile conf/ssl.crt/server.pem
SSLCertificateKeyFile conf/ssl.crt/server.key
SSLCACertificateFile conf/ssl.crt/cas.pem

SSLInsecureRenegotiation on

SSLOptions +StdEnvVars +ExportCertData

LogLevel debug

Con esta configuración, para usar el SSL, dentro del httpd.conf basta con añadir Include conf/ssl.conf
Crear certificados de pruebas
Por lo general es necesario disponer de certificados de pruebas durante el desarrollo de una aplicación. Dado que en el Apache se añadieron las CAs de la FNTM y la policía, se podrán usar los certificados de la seguridad social o el DNI electrónico, si se dispone de ellos.
Otra opción es la de generar nuestros propios certificados de pruebas, por ejemplo para simular distintos tipos de usuarios. Su creación es muy sencilla, ya que incluso se pueden hacer con el KeyStoreExplorer (generando nuevo keyPair y exportándolo en formato p12), pero para poder emplearlo es necesario que estén avalados por alguna CA en la que confíe el servidor. Es aquí donde entra la CA que se creó en el apartado anterior.
Los pasos a seguir son:
  • Crear certificado de pruebas.
  • Crear solicitud de firma.
  • Realizar la firma con la CA.
El programa utilizado será el OpenSSL.
Se crea un fichero config.txt con el siguiente contenido:

basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth

Lo primero es crear la clave privada del certificado cliente

openssl genrsa -des3 -passout pass:password -out client-priv.pem 2048

Con esto generamos la clave privada la cual tendrá un algoritmo de cifrado triple des (-des3) de 2048 y se almacenara en el fichero (-out) client-priv.pem y con el comando -passout pass: indicamos la contraseña para nuestra clave privada.
El siguiente paso es generar la petición del certificado para indicar el propietario del mismo:

openssl req -new -key client-priv.pem -passin pass:password -subj "/CN=NOMBRE Julius Robert Oppenheimer - NIF 30303030R/OU=registroComercio.com/DN=registroComercio.com" -out petic-cert-client.pem

Con el parámetro -subj le indicamos a quien pertenece el certificado, y lo estructuramos simulando que se trata de un certificado de la FNMT . Le asociamos a la petición la clave privada que hemos hecho en el comando anterior -key client-priv.pem  utilizando la contraseña de la clave privada -passing pass:password. La petición se almacenará en el fichero petic-cert-client.pem
Teniendo la request de firma, se emplea nuestra CA (clave privada y certificado) para firmarlo y generar un certificado válido.

openssl x509 -CA cacert.pem -CAkey cakey.pem -req -in petic-cert-client.pem -set_serial 3 -days 3650 -extfile config.txt -sha1 -out client-cert.pem

Los parámetros de entrada son los dos ficheros de la CA, la petición de firma y el fichero de configuración del comando.
El certificado tendrá una validez de 10 años, el número de certificado indicado con el parámetro-set_serial debería ser único, con lo que habría que ir cambiándolo si se hiciesen más certificados.
Como salida se genera el fichero client-cert.pem
En este punto ya tenemos completo le certificado cliente, aunque en dos ficheros separados:
  • Clave privada: client-priv.pem
  • Parte pública: client-cert.pem

Por último, se agrupa todo el certificado en un único fichero pkcs12 (similar a un keystore).

openssl pkcs12 -export -in client-cert.pem -inkey client-priv.pem -certfile cacert.pem -out cert-cliente.p12
Esta acción pedirá el password de la clave privada (que se creó al comienzo del proceso y en este caso es password), así como la clave de acceso al nuevo fichero.
Como resultado obtendremos el fichero cert-cliente.p12, listo para instalar en cualquier navegador.
Como este fichero es un keystore, se puede abrir con el KeyStoreExplorer para comprobar su contenido.
Haciendo esto se comprueba que es un certificado firmado por la CA de pruebas y que contiene la información que se le había indicado.
Para algunos usos, por ejemplo el jmeter, puede ser interesante disponer de un keystore en formato jks formado por ese certificado completo. Para ello se puede utilizar el programa keytool que viene con las últimas distribuciones de java.

keytool -importkeystore -srckeystore cert-cliente.p12 -srcstoretype pkcs12 -destkeystore cert-cliente.jks -deststoretype JKS

Otra opción es emplear el propio KeyStoreExplorer, creando un nuevo jks e importando el certificando usando la opción import keypair.