Es importante mantener el tema de mysql, por tradicion, de hecho existe hoy en esta distribucion de Linux Centos se instala por omision con MARIADB, pero porque algunos todavia tenemos aplicaciones en Mysql resulta necesario poder tener esta posibilidad.
URL de Referencia: Instalar Mysql en Centos7
sábado, septiembre 26, 2015
sábado, septiembre 19, 2015
Instalar pluguin anticaptcha en Jdownloader2
Tomado de: Articulo original
Aún recuerdo cuando instalabas tu plugin y bajas un paquete de cientos de imágenes de Captcha para evitar escribirlas y fueran automáticamente con el sistema, pero ya no es así o al menos no di con ese plugin.
Siempre he usado Jdownloader y lo uso casi para todo por lo que este plugin va perfecto. Todos odiamos el captcha de una u otro manera ya que nos quita tiempo y nos induce a la necesidad de estar en la pc esperando los minutos para poder descargar nuestro siguiente archivo. En estos tutoriales voy a brindarles el plugin anticaptcha 2015 incluso viene con pruebas para que vean que no les estoy mintiendo.
Funciona con todos los servidores que maneja Jdownloader.
No solo funciona con Jdownloader, también con varios se puede implementar ya sea Mypony , no he probado con otros pero si alguien lo ha hecho no estaría mal que nos diga.
Su configuracion es sencilla y de facil integracion
Solo se necesita el Gestor de descargas para poder implementarlo en mi caso Jdownloader
Aun que la principal desventaja de
este metodo se difiere en dos partes una podria ser la mas facil la
otra sera por eleccion propia:
Ya registrados tendremos que revisar nuestra bandeja de correo electrónico donde se nos enviara un email con los datos para poder ingresar. Inmediatamente nos iremos para generar nuestra apikey aquí http://www.9kw.eu/userapi.html y donde dice One-Click API Key daremos clic en Jdownloader para que genere una apikey que usaremos y aparecerá algo así
Aqui un video del mismo autor para que se tenga una mejor guia:
Video Relacionado
Plugin: Anticapcha 2015 Jdownloader
Sin duda lo más odioso al usar un filehoster son sus Captcha, algunos pensaran que el simple hecho de usar un filehoster dígase mediafire, rapidshare, depositfiles, el nuevo Mega etc estamos hablando de piratería y no es así, hay muchas cosas compartidas por los propios autores en estos filehosters que no infringe el copyright digamos distribuciones de Linux, tutoriales, vídeos, pdfs de programación para android, php, HTML, algunos plugins de wordpress subidos por los propios autores entre otras cosas pero no venimos a discutir eso.
Hace poco encontré una serie de tutoriales para backtrack, programación en android y algunos scripts gratuitos en diferentes filehosters una larga lista de al menos 100 archivos lo tedioso es que no cuento con cuentas Premium y tenía que poner los Captchas y esperar el tiempo de restricción por lo que recordé que existían algunos plugins para evitar esto los Anti Recaptcha.Aún recuerdo cuando instalabas tu plugin y bajas un paquete de cientos de imágenes de Captcha para evitar escribirlas y fueran automáticamente con el sistema, pero ya no es así o al menos no di con ese plugin.
Siempre he usado Jdownloader y lo uso casi para todo por lo que este plugin va perfecto. Todos odiamos el captcha de una u otro manera ya que nos quita tiempo y nos induce a la necesidad de estar en la pc esperando los minutos para poder descargar nuestro siguiente archivo. En estos tutoriales voy a brindarles el plugin anticaptcha 2015 incluso viene con pruebas para que vean que no les estoy mintiendo.
VENTAJAS Y DESVENTAJAS del Plugin Anticapcha Jdowloader 2015
VENTAJASFunciona con todos los servidores que maneja Jdownloader.
No solo funciona con Jdownloader, también con varios se puede implementar ya sea Mypony , no he probado con otros pero si alguien lo ha hecho no estaría mal que nos diga.
Su configuracion es sencilla y de facil integracion
Solo se necesita el Gestor de descargas para poder implementarlo en mi caso Jdownloader
DESVENTAJAS
Aun que la principal desventaja de
este metodo se difiere en dos partes una podria ser la mas facil la
otra sera por eleccion propia:
1.-
Tendremos que llenar captchas hasta juntar los suficientes para poder
dejar descargando Jdownloader o el gestor de descarga propio, se maneja
por creditos.
2.- Podremos pagar para tener ciertos creditos
Como usar el PluginAnticapcha en Jdownloader.
Una recomendación es usar Jdownloader 2. Primero que nada tendremos que registrarnos en http://www.9kw.eu para poder descargar el complemento para Jdownloader ya que necesitaremos la apikey de nuestra cuenta para que funcioneYa registrados tendremos que revisar nuestra bandeja de correo electrónico donde se nos enviara un email con los datos para poder ingresar. Inmediatamente nos iremos para generar nuestra apikey aquí http://www.9kw.eu/userapi.html y donde dice One-Click API Key daremos clic en Jdownloader para que genere una apikey que usaremos y aparecerá algo así
| Name: | Key | Date | Aktiv |
| JDownloader | GXXXXXXXXXXXXXXXXXX | XXXXX | YES (ACTIV |
Agregando la apikey a nuestro Jdownloader 2
Nos iremos a Opciones y de ahí buscaremos en el menú de lado derecho opciones avanzadas y editaremos algunas opciones : Captcha9kwSettings.apikeyAQUÍ PONDREMOS NUESTRA API KEY y haremos clic en Captcha9kwSettings.enabled + Captcha9kwSettings.mouseEstablecer CaptchaSettings.captchadialog9kwtimeout a 300.000
CaptchaSettings.captchaexchangeservicesenabled debe hacer clicAhora viene la parte mala tendremos que ganar créditos para que funcione el plugin en jdownloader en el apartado de captcha solo tenemos que dar start y resolver unas cuantas captchas cada captcha nos dará 8 a 10 créditos con 250 son suficientes para descargar una tanda de 50 archivos en nuestro Jdownloader.
Aqui un video del mismo autor para que se tenga una mejor guia:
Video Relacionado
lunes, septiembre 14, 2015
Scroll Horizontal y Vertical de una Grilla en Genexus
Un ejemplo de como realizar Scroll Horizontal y Vertical, revisar las instrucciones:
Hacer SCROLL con Genexus.
Para quienes utilizan WorkWithPlus, aqui se tiene un ejemplo de como hacerlo:
Ejemplo con el Patron WorkWithPlus
Un Ejemplo mas Elaborado: Ejemplo de SCROLL con HTML Embebido
Otra alternativa, cuyo ejemplo se tomo del Foro de genexus:
Ejemplo de Scroll desde Genexus
Una forma de hacerlo es declarando 2 text block con formato tipo "Raw HTML"
y colocarlos en el web panel o web tran. uno al inicio de la grilla y el otro al final
Luego en el event star colocar lo siguiente:
T11.Format = 2 // raw html
T12.Format = 2 // raw html
// scrool grid
T11.caption= '<div style="overflow:auto;height:200px;width:800px;align:left;MARGIN: 0px 0px 0px 0px ;'
T11.caption+= 'scrollbar-face-color : #68838B;'
T11.caption+= 'scrollbar-highlight-color : #7A8B8B;'
T11.caption+= 'scrollbar-3dlight-color : #000000;'
T11.caption+= 'scrollbar-shadow-color : #000000;'
T11.caption+= 'scrollbar-darkshadow-color : #000000;'
T11.caption+= 'scrollbar-track-color : #000000;'
T11.caption+= 'scrollbar-arrow-color : #000000;'
T11.caption+= '">'
T12.caption = '</div>'
Hacer SCROLL con Genexus.
Para quienes utilizan WorkWithPlus, aqui se tiene un ejemplo de como hacerlo:
Ejemplo con el Patron WorkWithPlus
Un Ejemplo mas Elaborado: Ejemplo de SCROLL con HTML Embebido
Otra alternativa, cuyo ejemplo se tomo del Foro de genexus:
Ejemplo de Scroll desde Genexus
Una forma de hacerlo es declarando 2 text block con formato tipo "Raw HTML"
y colocarlos en el web panel o web tran. uno al inicio de la grilla y el otro al final
Luego en el event star colocar lo siguiente:
T11.Format = 2 // raw html
T12.Format = 2 // raw html
// scrool grid
T11.caption= '<div style="overflow:auto;height:200px;width:800px;align:left;MARGIN: 0px 0px 0px 0px ;'
T11.caption+= 'scrollbar-face-color : #68838B;'
T11.caption+= 'scrollbar-highlight-color : #7A8B8B;'
T11.caption+= 'scrollbar-3dlight-color : #000000;'
T11.caption+= 'scrollbar-shadow-color : #000000;'
T11.caption+= 'scrollbar-darkshadow-color : #000000;'
T11.caption+= 'scrollbar-track-color : #000000;'
T11.caption+= 'scrollbar-arrow-color : #000000;'
T11.caption+= '">'
T12.caption = '</div>'
martes, septiembre 08, 2015
Convertir archivos de Firmas Electronicas P12 a JKS
Generalmente servidores web basados en Java como Tomcat utilizan keytool ,
una utilidad Java, para crear las claves públicas, privadas y los
certificados asociados con este par de claves.
Los certificados se utilizan como firmas digitales , que proporciona una autenticación segura cuando se conectan los clientes a un servidor.
Keytool genera un almacen de claves , que tienen certificados de seguridad.
Los Keystores pueden utilizar el formato P12 o JKS .
P12 archivos son casi universalmente compatibles, pero el formato es extremadamente complejo.
Es posible utilizar keytool para convertir P12 a JKS , un formato más sencillo sólo se puede acceder a través de las aplicaciones Java.
Aqui las Instrucciones :
1.- Haga clic en " Inicio". Escriba " cmd" en el cuadro de búsqueda y luego presionar "Enter " para abrir el símbolo del sistema .
2.-Tipo "cd /" sin las comillas en la aplicación de línea de comandos y presione "Enter " para acceder a la carpeta raíz.
3.- Escriba "cd " seguido por el pleno del ruta de acceso que une al directorio donde se guarda el almacén de claves
4.-Escriba lo siguiente en el símbolo del sistema para convertir P12 a JKS :
keytool- importkeystore - srckeystore keystore.p12 - srcstoretype PKCS12 - deststoretype keystore.jks JKS - destkeystore
Pulse " Enter" después de cada comando para convertir P12 a JKS en Keytool .
Es posible que se le pida para crear una nueva contraseña para el almacén de claves JKS , se recomienda que utilice la misma contraseña del almacén de claves originales
Para hacer uso en un servidor de una comunicación https donde los datos viajan cifrados y sin que otras partes salvo el usuario y el servidor puedan acceder a los datos necesitamos un certificado digital. Un certificado es un archivo que contiene la clave pública sirviéndonos para verificar su autenticidad. Un certificado autofirmado es un certificado firmado con la misma clave privada asociada a la clave pública que contiene el certificado. Un certificado autofirmado es suficiente para un entorno de pruebas pero en un servidor para proporcionar confianza a los usuarios deberemos solicitar que una autoridad de certificados que nos firme con su clave nuestro certificado, si el usuario confía en esa autoridad de certificado puede de esta manera confiar en nuestro certificado y clave pública. Varias entidades de registro de dominios o halojamiento web ofrecen la compra de certificados SSL, en el artículo Certificado SSL, de empresa, «wildcard» y de validación extendida comento con un poco más detalle los varios tipos de certificados y algunas opciones donde obtenerlos o comprarlos.
Dependiendo del tipo de certificado que solicitemos y nos entregue la autoridad de certificado el usuario podrá ver que está simplemente accediendo a un servidor con conexión segura, ver los detalles de nuestro certificado y en algunos casos el usuario podrá ver en la barra de direcciones en verde el nombre de la entidad, que puede darle al usuario más confianza y ver que realmente está accediendo al servidor correcto y no a uno que esté intentando suplantar una identidad. En este último caso la barra de direcciones no tendría en verde el nombre de la entidad, esto es algo que como usuarios debemos comprobar al acceder a determinados sitios de forma segura.
Con la herramienta OpenSSL y los siguientes comandos podemos generar claves y certificados y realizar las conversiones entre formatos que necesitemos.
$ openssl pkcs12 -export -out localhost.p12 -inkey localhost.key -in localhost.crt
Aqui unos ejemplos:
Los dos comandos siguientes convertir el archivo pfx a un formato que puede ser abierto como un Java PKCS12 almacén de claves:
Tenga en cuenta que el nombre proporcionado en el segundo comando es el alias de tu clave en el nuevo almacén de claves.
Referencia
Usted puede verificar el contenido del almacén de claves utilizando el programa de utilidad keytool de Java con el siguiente comando:
Si desea respaldar su certificado para utilizar en el mismo u otro servidor web también con Java solo necesita copiar el archivo .keystore a un medio extraible.
Si desea exportar su certificado para importar en otro servidor web sin Java deberá descargar e instalar un programa externo para poder hacerlo ya que la herramienta keytool no cuenta con un comando para extraer la clave privada del .keystore.
Alguno de los programas que le permitirán hacer la exportación de la clave privada son: KeyTool-IUI, Portecle, Keystore Explorer
Para utilizar su archivo .pfx o .p12 como keystore para tomcat debe ejecutar el siguiente comando:
Su keystore se encuentra ahora listo para ser configurado en tomcat modificando el archivo server.xml de la siguiente forma:
keystoreType="PKCS12"
keystoreFile="archivo.p12"
keystorePass=Contraseña
Cualquiera de estos programas tienen la opción de abrir un .pfx o .p12 y guardarlo como .jks o .keystore cambiando el formato de manera sencilla. En nuestra experiencia, todos ellos fallan en importar el archivo en formato .pfx o .p12 si existe la más mínima diferencia en formatos.
Si estos programas fallan en abrir su .pfx o .p12 deberá seguir estos pasos para convertir su certificado en un formato que estos programas puedan abrir.
(Puede descargar openssl para Windows de aqui)
Extraer su clave privada y convertirla
Extraer sus certificados
Generar keystore
Ahora debe crear un nuevo keystore vacío utilizando alguno de los programas mencionados e importar la clave privada y el certificado extraídos, ya sea por separado (KeyTool-IUI) o concatenando los certificados al archivo de la clave (Portecle)
Concatenar archivos
Windows
Linux
Para convertir un keystore JKS (.jks) a un archivo PKCS12 (p.12), ejecute el siguiente comando:
NOTA: Este comando es compatible con versiones de JDK/JRE 1.6 o mayores. Keytool es una herramienta de terceros.
keytool -importkeystore -srckeystore [MY_KEYSTORE.jks] -destkeystore [MY_FILE.p12]
-srcstoretype JKS - deststoretype PKCS12 -deststorepass [PASSWORD_PKCS12]
Lista de parametros:
MY_KEYSTORE.jks: ruta del archivo keystore que desea convertir.
MY_FILE.p12: ruta del archivo PKCS12 (.p12 o extension .pfx) que se crear.
PASSWORD_PKCS12: la contraseña del archivo PKCS12.
Para verificar el contenido del archivo PKCS12, ejecute el siguiente comando:
keytool -list -v -keystore MY_FILE.p12 -storetype pkcs12
Esta operación requirirá las dos programas Keytool y OpenSSL, y una utilidad de Weblogic específicas también.
Convertir PFX al JKS En Weblogic
PFX es un formato de certificados SSL que se utilice en Windows que combina ambos el archivo de todos los certificados SSL de la cadena de confianza que contine el archivo de la llave pública y la llave privada asociada en un solo archivo .PFX.
Con el fin de convertir sus archivos de certificado en un formato que se puede utilizar por un servidor basado en Java, usted tendrá que extraer primero los certificados y la llave privada de su archivo PFX mediante el programa OpenSSL, y luego importar el CERT a su Keystore "Almacén de Llaves" usando el programa Keytool.
Los certificados se utilizan como firmas digitales , que proporciona una autenticación segura cuando se conectan los clientes a un servidor.
Keytool genera un almacen de claves , que tienen certificados de seguridad.
Los Keystores pueden utilizar el formato P12 o JKS .
P12 archivos son casi universalmente compatibles, pero el formato es extremadamente complejo.
Es posible utilizar keytool para convertir P12 a JKS , un formato más sencillo sólo se puede acceder a través de las aplicaciones Java.
Aqui las Instrucciones :
1.- Haga clic en " Inicio". Escriba " cmd" en el cuadro de búsqueda y luego presionar "Enter " para abrir el símbolo del sistema .
2.-Tipo "cd /" sin las comillas en la aplicación de línea de comandos y presione "Enter " para acceder a la carpeta raíz.
3.- Escriba "cd " seguido por el pleno del ruta de acceso que une al directorio donde se guarda el almacén de claves
4.-Escriba lo siguiente en el símbolo del sistema para convertir P12 a JKS :
keytool- importkeystore - srckeystore keystore.p12 - srcstoretype PKCS12 - deststoretype keystore.jks JKS - destkeystore
Pulse " Enter" después de cada comando para convertir P12 a JKS en Keytool .
Es posible que se le pida para crear una nueva contraseña para el almacén de claves JKS , se recomienda que utilice la misma contraseña del almacén de claves originales
Generar y convertir claves y certificados con OpenSSL
Usando los comandos expuestos en este artículo y con OpenSSL podemos crear una clave pública y privada para usarlo con ssh o para cifrar y descifrar mensajes, un certificado autofirmado que podremos usar en un servidor de aplicaciones para usar un protocolo seguro y también convertir las claves y certificados a uno de los formatos aceptados por la aplicación que usemos.
Para un uso personal como enviar correos o archivos cifrados o firmados digitalmente usar GnuPG es una buena opción. En Internet los servidores también se aprovechan del uso de criptografía para realizar comunicaciones seguras entre el usuario y el servidor.Para hacer uso en un servidor de una comunicación https donde los datos viajan cifrados y sin que otras partes salvo el usuario y el servidor puedan acceder a los datos necesitamos un certificado digital. Un certificado es un archivo que contiene la clave pública sirviéndonos para verificar su autenticidad. Un certificado autofirmado es un certificado firmado con la misma clave privada asociada a la clave pública que contiene el certificado. Un certificado autofirmado es suficiente para un entorno de pruebas pero en un servidor para proporcionar confianza a los usuarios deberemos solicitar que una autoridad de certificados que nos firme con su clave nuestro certificado, si el usuario confía en esa autoridad de certificado puede de esta manera confiar en nuestro certificado y clave pública. Varias entidades de registro de dominios o halojamiento web ofrecen la compra de certificados SSL, en el artículo Certificado SSL, de empresa, «wildcard» y de validación extendida comento con un poco más detalle los varios tipos de certificados y algunas opciones donde obtenerlos o comprarlos.
Dependiendo del tipo de certificado que solicitemos y nos entregue la autoridad de certificado el usuario podrá ver que está simplemente accediendo a un servidor con conexión segura, ver los detalles de nuestro certificado y en algunos casos el usuario podrá ver en la barra de direcciones en verde el nombre de la entidad, que puede darle al usuario más confianza y ver que realmente está accediendo al servidor correcto y no a uno que esté intentando suplantar una identidad. En este último caso la barra de direcciones no tendría en verde el nombre de la entidad, esto es algo que como usuarios debemos comprobar al acceder a determinados sitios de forma segura.
Con la herramienta OpenSSL y los siguientes comandos podemos generar claves y certificados y realizar las conversiones entre formatos que necesitemos.
Convertir un certificado a otros formatos
Dependiendo de la autoridad de certificado el certificado puede estar en diferentes formatos, dependiendo del servidor donde tengamos idea de usarlo podemos necesitar convertirlo a otro formato. También podemos usar OpenSSL para hacer las conversiones.Convertir un certificado en formato DER (.crt .cer .der) a PEM
| $ cat localhost.key localhost.crt > localhost.pem |
| $ openssl x509 -in localhost.crt -out localhost.pem |
| $ openssl x509 -inform der -in localhost.cer -out localhost.pem |
Convertir un certificado en formato PEM a DER
| $ openssl x509 -outform der -in localhost.pem -out localhost.der |
Convertir un archivo en formato PKCS#12 (.pfx .p12) que contiene una clave privada y certificado a PEM
| $ openssl pkcs12 -in localhost.p12 -out localhost.pem -nodes |
| $ keytool -importkeystore -destkeystore localhost.keystore -srckeystore localhost.p12 -srcstoretype pkcs12 |
Aqui unos ejemplos:
| openssl genrsa -out localhost.key 8192 |
| openssl req -new -key localhost.key -out localhost.csr |
| openssl x509 -outform der -in localhost.pem -out localhost.der |
| openssl pkcs12 -in localhost.p12 -out localhost.pem -nodes |
| keytool -importkeystore -destkeystore localhost.keystore -srckeystore localhost.p12 -srcstoretype pkcs12 |
| openssl rsa -in localhost.key -pubout > localhost.pub |
Otra forma enerar y convertir claves y certificados con OpenSSL
En primer lugar, asegúrese de que usted tiene OpenSSL instalado. Muchos sistemas operativos ya lo han instalado como he encontrado con Mac OS X.Los dos comandos siguientes convertir el archivo pfx a un formato que puede ser abierto como un Java PKCS12 almacén de claves:
openssl pkcs12 -in mypfxfile.pfx -out mypemfile.pem
openssl pkcs12 -export -in mypemfile.pem -out mykeystore.p12 -name "MyCert"
Tenga en cuenta que el nombre proporcionado en el segundo comando es el alias de tu clave en el nuevo almacén de claves.
Referencia
Usted puede verificar el contenido del almacén de claves utilizando el programa de utilidad keytool de Java con el siguiente comando:
keytool -v -list -keystore mykeystore.p12 -storetype pkcs12 keytool -importkeystore -srckeystore mykeystore.p12 -destkeystore clientcert.jks -srcstoretype pkcs12 -deststoretype JKS
Exportar e Importar con Java Keytool
Informacion de ReferenciaExportar su certificado a un archivo
Si desea respaldar su certificado para utilizar en el mismo u otro servidor web también con Java solo necesita copiar el archivo .keystore a un medio extraible.
Si desea exportar su certificado para importar en otro servidor web sin Java deberá descargar e instalar un programa externo para poder hacerlo ya que la herramienta keytool no cuenta con un comando para extraer la clave privada del .keystore.
Alguno de los programas que le permitirán hacer la exportación de la clave privada son: KeyTool-IUI, Portecle, Keystore Explorer
Importar su certificado desde un archivo
Para utilizar su archivo .pfx o .p12 como keystore para tomcat debe ejecutar el siguiente comando:
keytool -import -alias tomcat -keystore archivo.p12
Su keystore se encuentra ahora listo para ser configurado en tomcat modificando el archivo server.xml de la siguiente forma:
keystoreType="PKCS12"
keystoreFile="archivo.p12"
keystorePass=Contraseña
Convertir su certificado de .pfx o .p12 a .jks
Deberá contar con openssl y alguno de los programas que le permitirán convertir el formato de su certificado como por ejemplo: KeyTool-IUI, Portecle, Keystore ExplorerCualquiera de estos programas tienen la opción de abrir un .pfx o .p12 y guardarlo como .jks o .keystore cambiando el formato de manera sencilla. En nuestra experiencia, todos ellos fallan en importar el archivo en formato .pfx o .p12 si existe la más mínima diferencia en formatos.
Si estos programas fallan en abrir su .pfx o .p12 deberá seguir estos pasos para convertir su certificado en un formato que estos programas puedan abrir.
(Puede descargar openssl para Windows de aqui)
Extraer su clave privada y convertirla
openssl pkcs12 -in archivo.pfx -nocerts -nodes -out clavepriv.pem
openssl rsa -in clavepriv.pem -out convertpriv.pemExtraer sus certificados
openssl pkcs12 -in archivo.pfx -nokeys -out cert.pemGenerar keystore
Ahora debe crear un nuevo keystore vacío utilizando alguno de los programas mencionados e importar la clave privada y el certificado extraídos, ya sea por separado (KeyTool-IUI) o concatenando los certificados al archivo de la clave (Portecle)
Concatenar archivos
Windows
copy convertpriv.pem+cert.pem completo.pemLinux
cat convertpriv.pem cert.pem > completo.pemComo convertir un Keystore JKS al formato PKCS12 (.p12)
NOTA: Este comando es compatible con versiones de JDK/JRE 1.6 o mayores. Keytool es una herramienta de terceros.
keytool -importkeystore -srckeystore [MY_KEYSTORE.jks] -destkeystore [MY_FILE.p12]
-srcstoretype JKS - deststoretype PKCS12 -deststorepass [PASSWORD_PKCS12]
Lista de parametros:
MY_KEYSTORE.jks: ruta del archivo keystore que desea convertir.
MY_FILE.p12: ruta del archivo PKCS12 (.p12 o extension .pfx) que se crear.
PASSWORD_PKCS12: la contraseña del archivo PKCS12.
Para verificar el contenido del archivo PKCS12, ejecute el siguiente comando:
keytool -list -v -keystore MY_FILE.p12 -storetype pkcs12
Java Archivo .JKS Creación de un .PFX
Convertir de Formatos de Certificado de .PFX al .JKS
Tenga en cuenta que el objetivo de estas instrucciones es para mostrar cómo separar los certificados SSL y la llave privada para generar un archivo .PFX y combinarlos en un Keystore "Almacén de Llaves" de Java.Esta operación requirirá las dos programas Keytool y OpenSSL, y una utilidad de Weblogic específicas también.
Convertir PFX al JKS En Weblogic
PFX es un formato de certificados SSL que se utilice en Windows que combina ambos el archivo de todos los certificados SSL de la cadena de confianza que contine el archivo de la llave pública y la llave privada asociada en un solo archivo .PFX.
Con el fin de convertir sus archivos de certificado en un formato que se puede utilizar por un servidor basado en Java, usted tendrá que extraer primero los certificados y la llave privada de su archivo PFX mediante el programa OpenSSL, y luego importar el CERT a su Keystore "Almacén de Llaves" usando el programa Keytool.
- En primer lugar, Cree un Archivo .PFX desde el servidor de Microsoft si no lo ha hecho.
- En segundo lugar, ejecute el siguiente comando de OpenSSL para extraer sus certificados y la llave privada del archivo .PFX:
openssl pkcs12-in-out suDominio.pfx certificado_temporario.crt -nodes - Ahora debería tener un archivo llamado certificado_temporario.crt. Abra este archivo con un editor de texto (como WordPad) y verá la llave privada aparece en primer lugar, seguido por los archivos de su certificado:
----- BEGIN RSA PRIVATE KEY -----
(Bloque de Texto Cifrado)
----- END RSA PRIVATE KEY -----
- Cortar y pegar todo la llave privada, incluyendo el BEGIN y END etiquetas a un archivo de texto y guardarlo como su_dominio_com.key
- Los certificados que queda en su certificado_temporario.crt será en el siguiente orden, Certificado de Servidor, Certificado Intermedio, Certificado Raíz, dependiendo de su exportación PFX podría haber entre 2 y 4 certificados por separado dentro de este fichero.
- Con tal que haya exportado el certificado correctamente, tendrá toda lo necesario para guardar el certificado. Asegúrese de que la llave privada se quitó del archivo, y luego seguir adelante y guarde este archivo como su_dominio_com.pem.
- Si usted tiene acceso para iniciar sesión en su cuenta DigiCert, seguir adelante e iniciar sesión en, haga clic en el número de pedido y descargue el archivo TrustedRoot.crt.
- Si no, vaya de nuevo en el archivo vaya a abrir el archivo certificado_temporario.crt en un editor de texto y copie el segundo certificado incluso las etiquetas BEGIN CERTIFICATE y END CERTIFICATE en un archivo nuevo y nombre este archivo TrustedRoot.crt.
- Usted puede asegurarse de que haya elegido el archivo correcto, verificando que su TrustedRoot.crt se emitió por la misma organización. Nota: Debido al hecho de que DigiCert frecuentamente emite certificados firmado por unas otras autoridades de certificación para mejorar la compatibilidad en varias tipos de servidores y aplicaciones de cliente y servidor, la información de su certificado raíz puede ser diferente de lo que se muestra en la imagen de abajo.
- Cree una Almacén de Llaves de Autoridad Confiada-
Ejecutar las siguientes dos líneas como un comando (en una linea) en Keytool:
keytool -import -trustcacerts -file TrustedRoot.crt -alias servidor
-Keystore nuevo_almacen_confiado.jks -storepass NUEVACONTRASEÑA
Usted debe ingresar su contraseña después de -storepass en el código de encima.
- A continuación, se creará un Identidad Almacén de Certificados, Ejecute el siguiente comando:
-
java utils.ImportPrivateKey -keystore nuevo_almacen_identidad.jks -storepass
CONTRASEÑA -storetype JKS -keypass NUEVACONTRASEÑA -alias
servidor -certfile certificado_temporario.crt -keyfile su_dominio_com.key
-Keyfilepass PFXCONTRASEÑA
Entre su propia contraseña para el storepass-y-keypass atributos, por encima, y la contraseña de PFX que se habrían creado cuando el archivo PFX fue creado.
Ahora debe tener dos archivos, nuevo_almacen_confiado.jks y
nuevo_almacen_identidad.jks. Estos archivos deben estar listos para
estar habilitado para SSL en su servidor basado en Java.
Autenticación de cliente SSL en web services con Axis2
Normalmente uso Axis2 para crear mis clientes de web services; es
bastante sencillo ya que solamente hay que ejecutar el script wsdl2java
pasando el WSDL del web service y se genera una clase que contiene todo
lo necesario para invocar los métodos publicados en el servicio.
Recientemente, me topé con un web service que en pruebas funcionó muy bien pero resulta que en producción había que activar SSL (o sea https://blabla en el URL en vez de solamente http://blabla) y además tuve que implementar un esquema muy poco usual (aunque sea un estándar): autenticación de cliente con PKI (Public Key Infrastructure - Infraestructura de Llave Pública).
El funcionamiento de SSL por lo general es que solamente el servidor se autentica con el cliente, y luego el cliente se autentica de alguna forma específica a la aplicación. La manera en que funciona la autenticación del servidor en una conexión SSL es via PKI; el servidor utiliza un certificado X509 que contiene su información, una fecha de expiración, una llave pública (RSA por lo general) y algunos datos del emisor de dicho certificado. En PKI se maneja el concepto de cadena de confianza, que consiste en que para poder aceptar el certificado de alguien más como válido, es necesario conocer al emisor o emisores de dicho certificado, hasta llegar al certificado raíz; si todos son considerados válidos y conocidos por el cliente, entonces se puede considerar válido el certificado del servidor.
Con Axis2 o cualquier otra herramienta para web services, todo este mecanismo de autenticar al servidor se maneja ya de forma automática. De hecho quien se encarga es el mismo JRE, porque con el ambiente Java ya vienen incluidos los certificados raíz más populares, por lo que cualquier certificado emitido por ellos será aceptado como válido (siempre y cuando cumpla las otras condiciones, como que esté vigente, etc).
Pero en SSL también el servidor puede autenticar a los clientes de la misma forma, es decir, solicitando al cliente su certificado X509 para validarlo. Esto ya no se maneja de manera tan transparente en Java; una opción para lograr esto es tener el certificado cliente y la correspondiente llave privada, almacenados en el KeyStore del usuario que corre el programa que quiere hacer la conexión que requiere autenticación de cliente. Pero entonces hay que estar configurando el KeyStore de cada cliente, y eso puede ser problemático, o bien puede ser que ni siquiera tengamos permiso de modificar ese KeyStore y por lo tanto hay que usar un KeyStore privado.
Esto último fue mi caso: tengo una aplicación que invoca distintos web services y solamente uno de ellos me pide este esquema, por lo que no quiero modificar todo el KeyStore porque hay que hacerlo en desarrollo y luego en producción y cualquier otra persona que quiera invocar el web service tiene que hacer lo mismo. De modo que preferí hacer un KeyStore privado para este web service. En Axis2, necesitamos primero que nada crear una fábrica de sockets para el HttpClient que usa el cliente del web service. De modo que hay que implementar la interfaz
Ya que tenemos el KeyStore, necesitamos crear una KeyManagerFactory con el mismo:
Finalmente, ya que tenemos el KeyManagerFactory, debemos crear un SSLContext que es con el que vamos a crear los sockets que necesita el web service para enviar y recibir datos:
El objeto SSLContext es el que se debe usar en los métodos para crear
sockets de nuestra implementación de SecureProtocolSocketFactory. La
implementación es bastante directa, simplemente en cada método hay que
devolver un socket creado por el SSLContext con los parámetros
recibidos, por ejemplo:
Con esto apenas tenemos lo necesario para poder crear sockets SSL con
un contexto que permite autenticar al cliente si el servidor lo
requiere. Ahora tenemos que registrar este SecureProtocolSocketFactory
con nuestro web service, para el protocolo https (podríamos ponerle el
nombre que sea al protocolo; siempre y cuando usemos ese protocolo en el
URL, se va a usar nuestra fábrica de sockets). Si el web service lo
generamos usando Axis2 ADB con el programa wsdl2java (yo usé Axis2 1.5)
entonces:
Con lo anterior, si le pasamos al web service un URL que comience con https:// entonces se va a usar nuestra fábrica de sockets, la cual tiene el SSLContext que contiene el certificado y llave privada del archivo PKCS12 para poder autenticarse con el server. Si el servidor tiene un certificado válido emitido por una de las autoridades certificadas reconocidas por nuestra instalación de Java, ya estamos listos para invocar el web service via SSL.
Adicionalmente, si el servidor usa un certificado auto-firmado, al invocar el web service vamos a obtener un error porque Java no reconoce el certificado del servidor; en este caso, hay que hacer algo de trabajo adicional. Necesitamos obtener el certificado del servidor, y guardarlo en un archivo de KeyStore. Por seguridad, no recomiendo usar el KeyStore default del usuario, sino usar uno separado. Para ello necesitamos un archivo con el certificado y luego lo importamos a un nuevo KeyStore con la herramienta keytool (esto no es tan relevante para este post, simplemente hay que ver la documentación del programa keytool; al final tendremos un archivo tipo JKS protegido por un password).
Una vez que tenemos el archivo, debemos crear un TrustManagerFactory, de preferencia en el mismo lugar donde creamos el KeyManagerFactory (dentro de nuestra fábrica de sockets, antes de crear el SSLContext):
Con esto, ya tenemos un SSLContext que crea sockets para conexiones SSL donde se reconoce únicamente el certificado auto-firmado del servidor y que se van a autenticar con el certificado y llave privada del archivo PKCS12.
Estuve peleándome un buen rato con esto porque no hay mucha documentación, espero le sirva a alguien en el futuro. Aplica para Axis2, lo hice con 1.5 pero supongo que funciona con algunas versiones anteriores.
De hecho esto funciona para autenticar a un cliente con cualquier servidor SSL; en el caso de web services hay que encapsular todo esto en la implementación de SecureProtocolSocketFactory pero en caso de usar SSL puro, el código será muy similar aunque vaya encapsulado en algún componente distinto.
Recientemente, me topé con un web service que en pruebas funcionó muy bien pero resulta que en producción había que activar SSL (o sea https://blabla en el URL en vez de solamente http://blabla) y además tuve que implementar un esquema muy poco usual (aunque sea un estándar): autenticación de cliente con PKI (Public Key Infrastructure - Infraestructura de Llave Pública).
El funcionamiento de SSL por lo general es que solamente el servidor se autentica con el cliente, y luego el cliente se autentica de alguna forma específica a la aplicación. La manera en que funciona la autenticación del servidor en una conexión SSL es via PKI; el servidor utiliza un certificado X509 que contiene su información, una fecha de expiración, una llave pública (RSA por lo general) y algunos datos del emisor de dicho certificado. En PKI se maneja el concepto de cadena de confianza, que consiste en que para poder aceptar el certificado de alguien más como válido, es necesario conocer al emisor o emisores de dicho certificado, hasta llegar al certificado raíz; si todos son considerados válidos y conocidos por el cliente, entonces se puede considerar válido el certificado del servidor.
Con Axis2 o cualquier otra herramienta para web services, todo este mecanismo de autenticar al servidor se maneja ya de forma automática. De hecho quien se encarga es el mismo JRE, porque con el ambiente Java ya vienen incluidos los certificados raíz más populares, por lo que cualquier certificado emitido por ellos será aceptado como válido (siempre y cuando cumpla las otras condiciones, como que esté vigente, etc).
Pero en SSL también el servidor puede autenticar a los clientes de la misma forma, es decir, solicitando al cliente su certificado X509 para validarlo. Esto ya no se maneja de manera tan transparente en Java; una opción para lograr esto es tener el certificado cliente y la correspondiente llave privada, almacenados en el KeyStore del usuario que corre el programa que quiere hacer la conexión que requiere autenticación de cliente. Pero entonces hay que estar configurando el KeyStore de cada cliente, y eso puede ser problemático, o bien puede ser que ni siquiera tengamos permiso de modificar ese KeyStore y por lo tanto hay que usar un KeyStore privado.
Esto último fue mi caso: tengo una aplicación que invoca distintos web services y solamente uno de ellos me pide este esquema, por lo que no quiero modificar todo el KeyStore porque hay que hacerlo en desarrollo y luego en producción y cualquier otra persona que quiera invocar el web service tiene que hacer lo mismo. De modo que preferí hacer un KeyStore privado para este web service. En Axis2, necesitamos primero que nada crear una fábrica de sockets para el HttpClient que usa el cliente del web service. De modo que hay que implementar la interfaz
org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory.
En mi caso, recibí el certificado y la llave privada en un archivo de
tipo PKCS#12, un formato que permite almacenar precisamente una serie de
llaves privadas y sus correspondientes certificados, protegido todo por
un password. Afortunadamente, Java permite leer este tipo de archivos
como un KeyStore. Simplemente hay que hacer lo siguiente:
String password = "el password del archivo PKCS12"
java.security.KeyStore ks = KeyStore.getInstance("PKCS12"); InputStream stream = //obtener de alguna manera un InputStream para el contenido del archivo PKCS12
ks.load(stream, password.toCharArray());
stream.close();
java.security.KeyStore ks = KeyStore.getInstance("PKCS12"); InputStream stream = //obtener de alguna manera un InputStream para el contenido del archivo PKCS12
ks.load(stream, password.toCharArray());
stream.close();
javax.net.ssl.KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, password.toCharArray());
kmf.init(ks, password.toCharArray());
Finalmente, ya que tenemos el KeyManagerFactory, debemos crear un SSLContext que es con el que vamos a crear los sockets que necesita el web service para enviar y recibir datos:
javax.net.ssl.SSLContext ssl = SSLContext.getInstance("SSL"); //Otra opcion es TLS
ssl.init(kmf.getKeyManagers(), null, null); //El segundo parametro es una lista de TrustManagers, si pasamos null se usan los de default de Java //El tercer parametro es un SecureRandom, si pasamos null si usa el default de Java
ssl.init(kmf.getKeyManagers(), null, null); //El segundo parametro es una lista de TrustManagers, si pasamos null se usan los de default de Java //El tercer parametro es un SecureRandom, si pasamos null si usa el default de Java
public Socket createSocket(String host, int port, InetAddress localHost, int localPort)
throws IOException, UnknownHostException {
return ssl.getSocketFactory().createSocket(host, port, localHost, localPort); }
throws IOException, UnknownHostException {
return ssl.getSocketFactory().createSocket(host, port, localHost, localPort); }
NuestraSubclaseDeSecureProtocolSocketFactory fabrica = //esta la debemos tener ya lista
org.apache.commons.httpclient.protocol.Protocol proto = new Protocol("https", fabrica, 443); //El protocolo tiene el nombre, la fabrica de sockets, y el puerto default a donde deben conectarse
miWebServiceStub._getServiceClient().getOptions().setProperty(HTTPConstants.CUSTOM_PROTOCOL_HANDLER, proto);
org.apache.commons.httpclient.protocol.Protocol proto = new Protocol("https", fabrica, 443); //El protocolo tiene el nombre, la fabrica de sockets, y el puerto default a donde deben conectarse
miWebServiceStub._getServiceClient().getOptions().setProperty(HTTPConstants.CUSTOM_PROTOCOL_HANDLER, proto);
Con lo anterior, si le pasamos al web service un URL que comience con https:// entonces se va a usar nuestra fábrica de sockets, la cual tiene el SSLContext que contiene el certificado y llave privada del archivo PKCS12 para poder autenticarse con el server. Si el servidor tiene un certificado válido emitido por una de las autoridades certificadas reconocidas por nuestra instalación de Java, ya estamos listos para invocar el web service via SSL.
Adicionalmente, si el servidor usa un certificado auto-firmado, al invocar el web service vamos a obtener un error porque Java no reconoce el certificado del servidor; en este caso, hay que hacer algo de trabajo adicional. Necesitamos obtener el certificado del servidor, y guardarlo en un archivo de KeyStore. Por seguridad, no recomiendo usar el KeyStore default del usuario, sino usar uno separado. Para ello necesitamos un archivo con el certificado y luego lo importamos a un nuevo KeyStore con la herramienta keytool (esto no es tan relevante para este post, simplemente hay que ver la documentación del programa keytool; al final tendremos un archivo tipo JKS protegido por un password).
Una vez que tenemos el archivo, debemos crear un TrustManagerFactory, de preferencia en el mismo lugar donde creamos el KeyManagerFactory (dentro de nuestra fábrica de sockets, antes de crear el SSLContext):
String pass2 = "el password del keystore que contiene el certificado del servidor";
javax.net.ssl.TrustManagerFactory tmf = TrustManagerFactory.getInstance(
TrustManagerFactory.getDefaultAlgorithm()); KeyStore ks2 = KeyStore.getInstance("JKS"); InputStream stream2 = //obtener un InputStream al archivo tipo JKS que generamos con keytool y que contiene el certificado auto-firmado del servidor
ks2.load(stream2, pass2.toCharArray());
stream2.close();
tmf.init(ks2); //Modificamos el inicializador de nuestro SSLContext, el segundo parametro ya tiene valor
ssl.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
javax.net.ssl.TrustManagerFactory tmf = TrustManagerFactory.getInstance(
TrustManagerFactory.getDefaultAlgorithm()); KeyStore ks2 = KeyStore.getInstance("JKS"); InputStream stream2 = //obtener un InputStream al archivo tipo JKS que generamos con keytool y que contiene el certificado auto-firmado del servidor
ks2.load(stream2, pass2.toCharArray());
stream2.close();
tmf.init(ks2); //Modificamos el inicializador de nuestro SSLContext, el segundo parametro ya tiene valor
ssl.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
Con esto, ya tenemos un SSLContext que crea sockets para conexiones SSL donde se reconoce únicamente el certificado auto-firmado del servidor y que se van a autenticar con el certificado y llave privada del archivo PKCS12.
Estuve peleándome un buen rato con esto porque no hay mucha documentación, espero le sirva a alguien en el futuro. Aplica para Axis2, lo hice con 1.5 pero supongo que funciona con algunas versiones anteriores.
De hecho esto funciona para autenticar a un cliente con cualquier servidor SSL; en el caso de web services hay que encapsular todo esto en la implementación de SecureProtocolSocketFactory pero en caso de usar SSL puro, el código será muy similar aunque vaya encapsulado en algún componente distinto.
lunes, septiembre 07, 2015
Ocultar y enmascarar URL
Resulta importante como un proceso de ocultamiento de URL para evitar que sea un agujero de seguridad mas, que resulte blanco de posible ataques por parte de Hackers.
Para ello se propone lo siguiente:
Pues bien, entonces lo que debes hacer para ocultar la url, es lo siguiente:
En el archivo http://www.tudominio.com/index.html debes insertar un iframe.
Para esto debes usar la etiqueta <iframe> que tiene la siguiente sintaxis:
Donde “xxxxxxxxx.html” debes reemplazarlo por la URL que quieres insertar y que será la que contendrá el contenido real que se moestrará, en este caso dijimos que seria http://www.tudominio.com/home.html
Entonces, dentro de http://www.tudominio.com/index.html, y luego de la etiqueta <body> debes colocar:
Con esto insertamos la “ventana” (iframe) por donde mostraremos el contenido del archivo home.html.
Y también dentro de http://www.tudominio.com/index.html, antes de la etiqueta de cierre </header> debes colocar el siguiente codigo CSS:
Con este codigo CSS, le decimos que la “ventana” del <iframe>
la lleve al mismo tamaño del navedador (máximo de alto y ancho).
Entonces cuando vayamos al URL http://www.tudominio.com/ (que es el que contiene el iframe), nos mostrará realmente el contenido del URL http://www.tudominio.com/home.html.
Y asi ocultaremos la URL real (http://www.tudominio.com/home.html).
Cualquiera que sea el motivo, vamos a ver cómo ocultar la dirección de destino de un enlace.
Para ello se propone lo siguiente:
Pues bien, entonces lo que debes hacer para ocultar la url, es lo siguiente:
En el archivo http://www.tudominio.com/index.html debes insertar un iframe.
Para esto debes usar la etiqueta <iframe> que tiene la siguiente sintaxis:
Donde “xxxxxxxxx.html” debes reemplazarlo por la URL que quieres insertar y que será la que contendrá el contenido real que se moestrará, en este caso dijimos que seria http://www.tudominio.com/home.html
Entonces, dentro de http://www.tudominio.com/index.html, y luego de la etiqueta <body> debes colocar:
<iframe src="http://www.tudominio.com/home.html"></iframe> |
Y también dentro de http://www.tudominio.com/index.html, antes de la etiqueta de cierre </header> debes colocar el siguiente codigo CSS:
<style type="text/css"> html, body, div, iframe { margin:0; padding:0; height:100%; } iframe { display:block; width:100%; border:none; }</style> |
Entonces cuando vayamos al URL http://www.tudominio.com/ (que es el que contiene el iframe), nos mostrará realmente el contenido del URL http://www.tudominio.com/home.html.
Código final y completo
Archivo http://www.tudominio.com/index.html:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Documento sin título</title> <style type="text/css"> html, body, div, iframe { margin:0; padding:0; height:100%; } iframe { display:block; width:100%; border:none; } </style> </head> <body> <iframe src="http://www.tudominio.com/home.html"></iframe> </body> </html> |
Y asi ocultaremos la URL real (http://www.tudominio.com/home.html).
COMO EN MASCARAR UNA URL
Cómo enmascarar la url de destino de un enlace de nuestras paginas web.
Cualquiera que sea el motivo, vamos a ver cómo ocultar la dirección de destino de un enlace.
- Requisitos para poder enmarcarar la URL de un enlace en servidores con Php.
Enmmascarar una URL en un enlace.
1.- Creamos una carpeta en el directorio llamada "publicidad".
2.- En la carpeta "publicidad" colocamos un archivo llamado "index.php" con este contenido:
<?php
$banner = $_GET['banner'];
// Enlaces que queremos disimular
$link[1] = "http://www.sobrasadascosme.es/afiliacion/?afiliado=983744";
$link[2] = "http://www.chorizoselfelix.es/afiliacion/?referido=982141";
$link[3] = "http://www.salchichasluisa.es/afiliating/?referida=234234";
header("HTTP/1.1 301 Moved Permanently");
header("Location: $link[$banner]");
header("Connection: close");
?>
A la hora de colocar enlaces de publicidad en nuestras páginas, el código Html a colocar sería este:
- Ocultando el archivo a los buscadores.
Si podemos acceder y retocar el archivo robots.txt de nuestro servidor, podemos evitar que los robots la rastreen, añadiendo a nuestro robots.txt las líneas:
User-agent: *
Disallow:/clic/- Editando el archivo .htaccess
Si tenemos acceso a nuestro archivo .htaccess y podemos editarlo, podemos usar este otro método más limpio en lugar del anterior. Basta con colocar en nuestro .htaccess lo siguiente:
RewriteEngine On
RewriteBase /
Redirect permanent /loqueyopongoenmiweb http://www.webdereferido.com/?referido=543256De ese modo si yo coloco un enlace a www.comocreartuweb.com/loqueyopongoenmiweb, el visitante irá dirigido a http://www.webdereferido.com/?referido=543256 que es la dirección que me dice la empresa de referidos que tengo que poner en mi web.
Si en tu .htaccess ya había código, coloca esas líneas al final del archivo. Si tras esos cambios la web deja de funcionar totalmente, te basta con eliminar esa línea y dejarlo como estaba. Será por algúna letra mal colocada, alguna línea en blanco al final o alguna tonteria equivalente. Si en tu .htaccess ya existían alguna de esas tres líneas (quiás ya tenías la primera y la segunda) solo necesitas añadir las que te falten, mejor no dupliques ninguna.
Suscribirse a:
Entradas (Atom)