Ya no tienes que indagar más por internet ya que has llegado al sitio indicado, poseemos la solución que necesitas sin problema.
Solución:
La solución alternativa es ponerse en contacto con GoDaddy y pedirle que vuelva a emitir el certificado de su organización. Durante el proceso de configuración del certificado, debe seleccionar un certificado de firma de código SHA-1 en lugar de SHA-2. La opción para seleccionar SHA-1 solo estará disponible si la validez de su certificado no se extiende hasta 2016 (ver más abajo), por lo que asegúrese de que comprendan que su objetivo final es volver a crear su certificado SHA-2 como SHA-1, para que sepan venderle un certificado con el período de validez correcto.
Cambié mi certificado SHA-2 por un SHA-1 hoy, y las instrucciones de firma de código Java de GoDaddy funcionaron perfectamente.
GoDaddy me informó que Keytool puede tener problemas para importar una cadena de respuesta de certificado generada a partir de su certificado de firma de código SHA-2 (longitud 2048). Retengo el juicio de Keytool ya que importa certificados SHA-2 correctamente cuando el certificado raíz SHA1 de GoDaddy se elimina del archivo pem según la respuesta de @ mogsie.
GoDaddy utiliza SHA-2 automáticamente cuando otorga certificados de codeign que se extenderán hasta 2017 porque Microsoft no aceptará menos de SHA-2 a partir del 1 de enero de 2016, por lo que si está buscando un certificado SHA-1, lo hará. tienen validez a corto plazo.
El problema podría desaparecer con una actualización de Java Keytool (estaba trabajando con 1.6), o si el certificado autofirmado Sha256withRSA de GoDaddy se vuelve ampliamente confiable.
La respuesta, como lo menciona Waterbear, es que GoDaddy vuelva a emitir o cambiar la clave de su certificado de GoDaddy usando SHA-1. los razón es que GoDaddy tiene dos servidores CA: Class 2 CA que se usa para firmar SHA-1 certificados, y G2 CA que se usa para firmar SHA-2 Certificados. Mientras que el mayor Class 2 CAes confiado por Java Truststore (y por lo tanto SHA-1 certificates son de confianza), el más nuevo G2 CA es no, entonces es SHA-2los certificados no son confiables a menos que instale manualmente su certificado raíz (lo que anula el propósito de comprar un certificado en primer lugar). Ojalá GoDaddy’s G2 CA pronto será de confianza para Java Truststore (¡antes de 2016!), pero hasta que eso suceda, GoDaddy SHA-2 cert no es mejor que un certificado autofirmado.
Como disfruté (no) tanto el proceso de creación de un certificado de codificación, pensé en compartir el proceso por el que pasé y, con suerte, cuando necesites generar el tuyo propio, esto te evitará algunos dolores de cabeza y dolor.
Usé godaddy, pero tengo que creer que quienquiera que sea el CA, los pasos deben ser muy similares.
Estos son los pasos que seguí:
(tenga en cuenta que godaddy no crea un certificado de firma de código en formato jks y hay un paso adicional involucrado para convertir el almacén de claves a jks)
Crear almacén de claves:
keytool -genkey -alias codeigncert -keypass yourpassword -keyalg RSA – keysize 2048 -dname “cn = server1.lccc.edu, OU = College Name, O = College Name, L = Schnecksville, ST = Pennsylvania, C = US” – keystore / home / oracle / codesignstore / codesignstore -storepass yourpassword -validity 720 (storepass y keypass pueden ser lo mismo)
Generater crt para godaddy
keytool -certreq -v -alias codesigncert – archivo /home/oracle/codesignstore/codesignstore.pem – keystore / home / oracle / codesignstore / codesignstore
usando un editor, abra codesignstore.pem y péguelo en el sitio de godaddy
cuando godaddy verifica la cuenta y usted paga su dinero, el estado ‘pendiente’ desaparecerá
ve a tu cuenta de godaddy (https://mya.godaddy.com/)
haga clic en mi cuenta en la parte superior de la página (en el encabezado negro)
haga clic en administrar certificados SSL
seleccione el certificado de firma de código enumerado
haga clic en el botón Iniciar
descargar el archivo como un archivo PEM
guárdalo en tu pc local
abra firefox, en la sección avanzada seleccione ver certificados, y el
El certificado debe aparecer en las vistas administradas.
resalte el certificado y seleccione copia de seguridad (exportar) y guárdelo como un archivo pkcs12
haga clic en ver certificados en la parte superior de la pantalla al lado del visor de certificados es el alias entre comillas dobles, a la derecha será el alias que se utilizará en el comando jarsigner a continuación
Copie el archivo en el servidor donde va a estar el certificado de firma de código.
utilizado: (por ejemplo, server1 / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12.p12) * este es el nuevo almacén de claves
Dado que el almacén de claves debe ser del tipo jks, y godaddy no crea un archivo jks, debe convertirse al formato jks.
convertir pcks12 a jks
keytool -importkeystore – srckeystore / home / oracle / code_sign_cert_from_godaddy / godaddy_pkcs12. p12 -srcstoretype pkcs12 – destkeystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks -deststoretype jks
procesamiento de archivos jar:
unsign jacob.jar … copié el archivo jacob.jar en un directorio de prueba / test_jacob y lo renombré jacob1.jar (nota 760815.1)
jar xf jacob1.jar
extrae en las carpetas “com” y “META-INF”, elimine la carpeta “META-INF”
eliminar el antiguo jacob1.jar
vuelva a crear jacob1.jar desde el directorio / test_jacob
jar -cvf jacob1.jar *
ejecute jarsigner -verify jacob1.jar, debería mostrar unisigned.
crear un archivo de texto llamado mymanifest.txt
Permissions: all-permissions
Codebase: *
Application-Name: OracleForms
jar -ufm jacob1.jar mymanifest.txt (esto coloca la nueva información del manifiesto en el archivo jar) ..
puede abrir jacob1.jar con el directorio unzip jacob1.jar -d donde se ubicará unzip para verificar que el archivo mymanifest.txt ahora es parte del archivo jar.
firmar archivo jar
jarsigner – keystore /home/oracle/code_sign_cert_from_godaddy/godaddy_jks.jks – storepass yourpassword –ignedjar / home / oracle / Oracle / Middleware / Oracle_FRHome1 / forms / java / tes t_jacob / Signedjacob1.jar jacob1.jar “lehigh carbon community college’s go. , inc. id “(este alias proviene del proceso de Firefox anterior)
se requería la opción de archivo -signedjar, sin ella recibía errores
tenga en cuenta que el alias es siempre la última entrada en el comando jarsigner y
no hay opción –alias como había en el comando keytool
verificar que el archivo jar esté firmado
jarsigner -verify Signedjacob1.jar mostrará:
jar verificado.
mostrar lo que hay en el archivo jar
jar -tvf Signedjacob1.jar
el archivo .SF está dentro del archivo .jar, el archivo .DSA se reemplaza por el .RSA
archivo que también está dentro del archivo .jar
desde la salida del jar -tvf Signedjacob1.jar
2721 Lun 05 de mayo 15:57:08 EDT 2014 META-INF / LEHIGH_C.SF
4231 Lun 05 de mayo 15:57:08 EDT 2014 META-INF / LEHIGH_C.RSA
Copié el archivo Signedjacob1.jar en el directorio $ ORACLE_HOME / forms / java y luego usé el
inicie sesión en el administrador empresarial de weblogic
Cambié el parámetro webutilarchive de Jacob.jar a Signedjacob1.jar para cada instancia
(em >> formularios >> configuración web >> nombre de instancia >> todos (la primera entrada debe ser el parámetro de archivo)
Al cambiar jacob.jar a Signedjacob1.jar, lo hice para cada una de mis instancias de prueba antes de hacerlo para producción, por si acaso.
Deténgase e inicie wls_forms y estará listo para comenzar.