En el momento de escribir esta guía, el sistema ATV no estaba funcionando y esta es una alternativa al mecanismo de contingencia en caso de que no puedan emitirse nuevos certificados generados por Hacienda para nuevos usuarios o para los certificados de usuarios existentes que ya hubieran vencido.
Quienes emitan comprobantes electrónicos pueden optar por esta modalidad, para la misma cédula con la que venía emitiendo los comprobantes, en el caso de la física usar la tarjeta de Firma Digital (si su proveedor de servicio ofrece firmar documentos en esta modalidad) y en el caso de las jurídicas mediante un certificado de Sello Electrónico, donde aquí se explica cómo generar un fichero .p12 que podría utilizarse de manera similar a como venía utilizando los .p12 de Hacienda.
Hay que recordar que los certificados de Sello Electrónico son de propósito general. No solamente sirven para firmar comprobantes electrónicos sino que pueden utilizarse por ejemplo para emisión de documentos oficiales de la empresa, por lo que debe asegurarse de que las personas que vayan a tener acceso al mismo son de su confianza. Las instituciones públicas en teoría están obligadas a emitir certificaciones y otros documentos equivalentes a su versión física con sello electrónico desde mediados de 2021. La empresas privadas también pueden aprovechar este tipo de certificado para temas similares, además de tener la ventaja de que este proceso se puede automatizar al no requerir ingresar PIN de desbloqueo de hardware (sí pueden tener para proteger el .p12 de todos modos) ni un dispositivo lento como es el caso de las tarjetas de Firma Digital para el procesado de gran cantidad de transacciones.
Cuando se habla de sello electrónico, no debe confundirse con el concepto de sello de tiempo, que es un concepto diferente. El sello electrónico es parecido a la firma digital de las personas físicas pero en este caso estas firmas representan la autoría de la persona jurídica como sucede con los sellos de empresa estampados en documentos en papel.
En el caso de los de Sello Electrónico, por el momento la autoridad certificadora autorizada por el Micitt es la del SINPE del Banco Central. Ofrecen un servicio de emisión de certificados “no custodiados” donde se puede generar una solicitud de certificado estándar (CSR, basado en PKCS #10) y cuando termina el proceso obtiene un certificado .crt para usarlo junto con su dispositivo para firmar.
Cuando se habla de dispositivo para firmar, se refiere a que aunque es una buena práctica utilizar un dispositivo de seguridad (HSM, tarjeta inteligente, etc.) donde se genere la o las llaves privadas y acceder al mismo mediante un PIN o frase de paso, donde así están planteadas las instrucciones de emisión de certificados de Sello Electrónico en la documentación que ofrece el Banco Central, todavía es posible generar la llave privada en un fichero de llaves (PKCS #1 / PKCS #8) como alternativa a un dispositivo hardware y luego combinarlo con el certificado descargado y los intermedios para generar un fichero PKCS #12 (.pfx o .p12) para utilizarlo de forma similar a los que se utilizaban en Hacienda, para los casos de personas jurídicas.
La guía original del BCCR está diseñada para ofrecer seguridad para proteger las llaves privadas como en el caso de las tarjetas de persona física. De hecho, antes de 2018 se solicitaba disponer de un dispositivo hardware homologado, pero para emisión masiva, estos dispositivos hardware tenían costos muy elevados o difíciles de obtener en el país, además de no necesariamente adaptarse a las necesidades de la empresa que requiriera firmar o haber restricciones en el uso de controladores para ciertos sistemas operativos. La normativa o el acuerdo de suscriptor no impide que se utilice fuera de un dispositivo hardware o que tenga que tratarse de un módulo hardware físico o virtual, por lo que esta guía no contradice estas recomendaciones, donde el usuario es responsable de la custodia y seguridad adecuada de estas llaves como mejor le convenga. Sería recomendable utilizar una frase de paso larga en el .p12 para que en caso de compromiso del sistema, con suerte no se haya podido captar la frase de paso y pueda haber tiempo de revocar las llaves de forma preventiva. Aunque de todos modos este procedimiento para las S.A. es rápido. es conveniente recordar que se puede solicitar más de un certificado en fechas diferentes para tener alguna contingencia en caso de requerir reemplazarlo (también es posible tener más de una tarjeta de firma digital en el caso de personas físicas por el mismo motivo).
Para emitir estos certificados se requiere que la persona física que es representante legal, apoderado generalísimo en el caso de sociedades anónimas y equivalentes en otras formas de personas jurídicas, disponga de Firma Digital, ya que deberá usarse para firmar la solicitud. En el caso de las sociedades anónimas además se puede emitir de forma inmediata, ya que el Banco Central se conecta a los servicios del Registro Nacional para verificar esta información, mientras que para otro tipo de personas jurídicas habría que solicitar a soporte de Central Directo para que verifiquen manualmente y tardan un poco más. El costo de la emisión del certificado es de 10.000 colones y tiene un periodo de validez de 4 años. El pago se realiza tras agregar la cuenta de la empresa y la transacción es automática mediante el sistema Débito a Tiempo Real (DTR).
Las siguientes instrucciones se basan en el uso de openssl y la guía que dispone el BCCR para Linux, que sin embargo también se puede realizar el proceso desde Windows y macOS si se descarga esta misma herramienta.
Cabe aclarar que lo que deberá solicitarse en Central Directo es un “sello electrónico”. El agente electrónico es para otro tipo de propósitos, básicamente para comunicación SSL/TLS certificada. El sello debe ser también de tipo “no custodiado”, ya que el custodiado es para consumirlo desde un servicio web mediante el sistema GAUDI del BCCR y tiene limitaciones adicionales sobre lo que se puede hacer con él y además cobran 1 colón por transacción por el uso de su API a las instituciones privadas. El “no custodiado” no tiene este tipo de limitaciones ni recargos adicionales por uso.
En el sitio web Proceso de emisión de certificados de persona jurídica y tras seguir los pasos indicados, se puede acceder a la “Guía Linux” mencionada anteriormente (importante recordar esta guía también es para el caso de Windows para obtener el .p12). Esta guía tiene 1 defecto que se aclarará a continuación, así como se indicarán un par de diferencias adicionales para poder generar la solicitud mediante llave privada en fichero para posterior ensamblado en el .p12 en lugar de requerir dispositivo hardware físico o virtual.
Deben seguirse los pasos de la guía que apliquen sello electrónico (los exclusivos de agente electrónico deben omitirse), excepto en este punto “e)”, que erróneamente se indicó que era exclusivo para agente electrónico pero también aplica para sello electrónico, donde se indica que hay que agregar una línea adicional en el fichero de configuración de openssl:
Esta aclaración es el defecto mencionado al principio. No olvide desactivar la línea basicConstraints=CA:FALSE de la sección [ v3_req ] colocando un # al inicio de la línea. El par de cambios que hay que realizar con respecto a la guía para que pueda emitirse utilizando llave privada desde fichero:
Saltarse todo este paso 5), no aplica para el caso de fichero de llave privada:
En su lugar, generar un sistema de llave RSA en fichero mediante el comando:
openssl genrsa -out llave.key
Ese fichero llave.key generado hay que conservarlo hasta que se haya generado el .p12 en el último paso, no debe ejecutarse este comando de nuevo porque generará una llave diferente, sobrescribiría el fichero y la llave no coincidiría con la del certificado generado posteriormente.
En el siguiente paso, hay que modificar el siguiente comando indicado en la guía:
En esta línea deben eliminar los parámetros que indican el uso del dispositivo hardware (-engine pkcs11 y -keyform engine) y reemplazar lo que está en rojo (id_01) con el nombre del fichero generado previamente (llave.key). Se recomienda no copiar el texto directamente de la guía PDF porque los “-” no son los mismos y generará un error “req: Use -help for summary.” en esos casos.
Ejemplo:
openssl req -new -key llave.key -subj "/2.5.4.5=CPJ-3-101-999999/CN=PRUEBA SOCIEDAD ANONIMA (SELLO ELECTRONICO)/O=PERSONA JURIDICA/C=CR" -out requestSello.req
Tras generarse el fichero requestSello.req, si todo fue bien tras haber realizado la firma y el pago podrá descargar el fichero de certificado .cer para finalmente ensamblar el .p12 con un comando como este (aquí se utiliza el llave.key conservado previamente, que será exclusivo para el certificado generado):
openssl pkcs12 -export -out llavero.p12 -inkey llave.key -in "Certificado PRUEBA SOCIEDAD ANONIMA (SELLO ELECTRONICO).cer"
En algunas versiones de openssl puede mostrar un mensaje “unable to load certificate” cuando el fichero de certificado está en formato DER. Si fuera el caso, debe convertirse a formato PEM con el comando openssl x509 -inform DER -outform PEM -in "Certificado en formato DER.cer" -out "Certificado en formato PEM.cer" y volver a intentar el comando del párrafo anterior.
Idealmente el .p12 debería incluir los certificados de la jerarquía de sello electrónico, aunque para firma básica (XAdES-Baseline-B o XAdES-EPES) como es en el caso de los comprobantes electrónicos no sería necesario agregar certificados intermedios adicionales en la mayoría de soluciones de facturación.
Nota: se han documentado casos donde los algoritmos de cifrado del fichero .p12 pueden no ser compatibles con versiones antiguas de Java, .net (como el ERP de Softland) o con las APIs de Azure websites (“contraseña de red no válida”) y se reporta que la siguiente línea de comandos funcionaría en estos casos: openssl pkcs12 -export -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -nomac -inkey llave.key -in "Nombre del certificado.cer" -out llavero.p12
Eso es todo. Muchos éxitos con su proceso de firmado de documentos en general.
Magnífico desarrollo del tema. Muy aapropiado para el momento.
Con gusto Álvaro, ojalá resulte útil a las personas jurídicas interesadas en este método.
Hola, nos puede ayudar a generar el archivo .p12?
Muchas gracias
Hola Oscar, claro, con mucho gusto. Le escribo por correo.
Sr. Francisco de la Peña
Sería posible contar con su asesoría para comprar nuestro sello electrónico y generar el .p12? Me gustaría saber cómo contactarla directamente para ver si podemos llegar a un acuerdo.
Buenas tardes, Carlos:
Claro, le escribo por el correo en el comentario. Saludos.
Se puede crear el archivo p12 para una persona física con firma digital?, cuanto cuesta?
Hola Jose: no, las personas físicas no pueden emitir certificados p12 con los certificados del BCCR-SINPE, solo pueden usar tarjeta de Firma Digital. En este caso los proveedores deberían disponer de mecanismos que permitan a los emisores de comprobantes de persona física que les permita firmar los XML “manualmente”, aunque sea con un firmador local y que permita subir de vuelta el XML firmado.
Por mi parte estoy preparando una versión del firmador libre para que firme comprobantes XML con Firma Digital. Espero tenerlo preparado pronto (quizás esta semana), para que puedan aprovecharlo quienes lo lo necesiten. Tiene interfaz gráfica pero también es posible invocarlo por línea de comandos suministrando el PIN como parámetro, por lo que es posible automatizarlo en los sistemas que lo deseen incorporar.
Los precios de Firma Digital varían según la institución donde lo solicite y según lo que requiera (lector, tarjeta, certificado). La lista de precios está en la sección de Firma Digital del BCCR.
Saludos.
Muy agradecido con esta guía. Es de mucha utilidad para muchos!
Alguna experiencia con razones sociales que excedan el límite de 64 caracteres permitidos en el /CN=
Con mucho gusto Daniel. Sí, hace como un par de años tuve que crear un sello con ese caso de nombre de persona jurídica demasiado largo para que cupiera en los 64 caracteres del CN. En uno de los pasos del proceso de crear el certificado se muestra un fichero de configuración (que no se usa para el caso de openssl) cuyos campos útiles (serialNumber o 2.5.4.5 y CN) dan una pista de cómo debería usarse, ya que ahí ya aparece recortado ajustado al límite de 64 caracteres. Ejemplo de nombre recortado que podría aparecer: NOMBRE DE EMPRESA MUY LARGO SOCIEDAD ANONI (SELLO ELECTRONICO)
Esto es una limitación técnica de la especificación x509 de certificados, pero aunque esté recortado y quede estéticamente imperfecto, seguirá siendo válido.
Saludos.
Hola Francisco, antes agradecer el aporte.
Siguiendo la guía que nos ofreciste para generar el P12, requiero por favor me pueda orientar con lo siguiente.
1. Con respecto al archivo RequestSello.req. Si se genera según la guía de central directo, puedo generar y descargar el archivo CER, pero si lo genero con el comando de la guía que planteas y solicitar el CER, no permite generarlo y presenta un error que indica que la llave no es válida.
2. En este punto, tengo un archivo llave.key que no puedo usar para generar el RequestSello.req, por lo tanto, al generar el P12, arroja un error de validez de la llave vs certificado.
No se en qué estaré fallando porque he seguido paso a paso ambos manuales, el suyo y el de central directo y la conclusión es que en central directo dan un comando para generar el RequestSello.req, diferente al comando que está en su guía y creo que ahí está el origen de la situación.
Agradezco me pudieras colaborar con esto
Hola Marco, en algún caso que he detectado por parte de usuarios que seguían la guía es que se estaban ejecutando todos los comandos después de descargar el certificado. El fichero llave.key debe conservarse ya que al generar el mismo .req que se firma y que se sube a Central Directo, al descargar el .cer se deberá utilizar con el mismo fichero llave.key que se generó al inicio. Si se vuelve a ejecutar el comando de “openssl genrsa” le caerá encima al fichero llave.key con un llave.key nuevo y ya no será la misma llave que corresponda con el certificado generado. Si en el proceso previo todo fue bien, el .p12 se podría generar sin problemas.
Pero no parece el caso, podría ser como apunta que se trate de que al ejecutar el comando para generar el req no se haya omitido parte del paso 5 de la guía o no se hayan eliminado las partes del engine pkcs11.
buenas yo genere mi sello , sin embargo aun no lo he podido descargar del banco central , solo tengo la evidencia firmada y un acuese en pdf no se donde descargar el p 12 para enviarselo al facturador, esto lo hago or que se me vencio mi llave criptografica, y no he podido facturar
Buenas, Sonia:
El proceso de asociar la persona representante legal y selección de la cuenta asociada para el DTR es el paso previo, luego al iniciar sesión en central directo aparece una opción para elegir persona jurídica con la cual operar y mostrará un menú arriba con las acciones, entre ellas, generar sello electrónico. En los pasos a seguir son los ue corresponderán con la “Guía Linux” para sello electrónico no custodiado, donde adjuntará el certificate request (fichero .req) creado como se indica en este blog. Si todo fue bien, en el último paso aparece la opción de descargar el fichero .cer, el cual es lo que se utilizará en la parte final de la guía para generar el .p12 con la llave privada que generó previamente siguiendo este artículo.
Estimado, una consulta, la clave o PIN donde se ingresa ? eso se hace en la página del BCCR al generar el certificado ?
Y esta clave no se ocupa para “empacar” el .cer en el .p12 ? es que no lo veo en los parámetros. Gracias.
Hola Eithel, el PIN se crea en el momento de ejecutar el último comando de la guía (openssl pkcs12 …), donde solicitará una contraseña de exportación. La solicitará dos veces para asegurarse de que la ingresó bien. Durante el tecleo no se verá nada en pantalla (ni asteriscos ni puntos) para que no se pueda deducir la longitud de la misma.
Es posible automatizar esto si ocupara pasarlo como parámetro, de lo contrario se utiliza de forma “interactiva” por consola. Saludos.
Buenas Francisco, estoy intentando generar el certificado p12 en el comando respectivo luego de seguir los pasos del manual pero este al digitar y ejecutar el pkcs12… queda el puntero como esperando algo más pero no solicita nada ni tampoco genera nada, entiendo que deberia solicitar el PIN 2 veces como indicas pero no pasa de una espera infinita. Que me podra estar haciendo falta?
Se me olvidaba indicar lo estoy ejecutando desde GIT BASH tendra algo que ver esto ya que el openssl que utilizo ese el propio de GIT…
Hola José, está raro ese caso, no creo que debiera haber ninguna diferencia al usar Git Bash. De todos modos, también es posible ejecutar el comando en una ventana normal de cmd si fuera necesario, donde se sabe que sí funciona al menos con las distribuciones de OpenSSL para Windows, que incluye también su propia consola que ya define la ruta de los ejecutables la variable de entorno Path.
podrías asesorarme en el proceso, ya que el archivo que se genera es un .cer con la guía proporcionada por el bcr y para transformarlo a .p12 me pide un archivo .key el cual no se genera. Gracias
Hola José, hay que seguir el procedimiento de la “Guía Linux” del BCCR aunque se use Windows, y aplicando las modificaciones descritas aquí, de lo contrario no se estará generando ni usando el archivo .key asociado al certificado. Si se siguió la “Guía Windows”, esa llave podría no ser extraíble y habría que solicitar otra.
gracias por tu pronta respuesta, estos request los puedo realizar desde cualquier equipo con la información pertinente a la empresa?
Con gusto. Sí, solo en lo que se deba realizar en el sitio de Central Directo por parte de la persona representante legal, solo ocupará que le mande el .req y luego que le devuelva de regreso el .cer para continuar.
Estimado Francisco
Es posible que nos pueda ayudar a crear P12.
Saludos Marco,
Claro, con gusto. Les escribo por correo.
Hola Francisco, segui el procedimiento y ya tengo mi certificado .pl2, sabras si en Softland hay algun “truco” para la clave o pin del certificado, que debo poner porque Softland me lo pide
Hola Carlos, en el ERP de Softland se reemplaza el p12 que se estaba utilizando con el nuevo, así como el campo de contraseña. Si apareciera un error de que la contraseña de red no es válida, hay que usar el comando alternativo indicado en esta guía al final, ya que Softland parece utilizar una versión de .net antigua que no soporta llaveros p12 con cifrados modernos pero utilizando los parámetros indicados al crear el .p12 de nuevo a partir de la llave.key y el certificado .cer debería funcionar porque se ha verificado con este ERP. Saludos.
Hola Francisco, se puede emitir un sello para el ambiente pruebas?
Hola Jose Alberto, puede usar el mismo p12 para desarrollo y producción. También puede disponer de más de un sello si lo prefiere.
Hola, consulta si ya tengo el archivo, que usuario y contraseña se utiliza?, antes se usaba la e 4 dígitos de hacienda y un usuario que desplegaba
Hola sara, si hizo el paso para generar el .p12, la contraseña es la que se crea nueva en el último comando de esta guía (el de “openssl pkcs12”), donde la solicita dos veces. Si el .p12 lo creó otra persona, habría que preguntar qué contraseña le agregó. Los certificados de hacienda suelen tener únicamente un pin de 4 dígitos y es fácil de averiguar.
Por cierto, hace unas horas parece que están revocando certificados de hacienda a muchas empresas. También han anunciado que podrán solicitarse nuevos certificados de Hacienda si se piden personalmente en sucursales.