De acuerdo, entonces DKIM usa solo crypto de publicación "sin procesar" y no certificados, pero alguna "aplicación" usa formato PKCS12 que requiere un certificado. Eso es bastante tonto.
Si tiene OpenSSL, y en Linux debería tener varias formas de crear un certificado autofirmado a partir de una clave privada. Un certificado autofirmado no cumple con el propósito principal por el que se diseñaron los certificados, de distribución de confianza desde una fuente (relativamente) centralizada, pero sí empaqueta una clave pública con algunos otros datos en forma de certificado, lo que a menudo es conveniente , incluyendo aquí.
La forma más sencilla es req -new -x509 algo así como:
openssl req -new -x509 -key privatekey.pem -days N -out dummy.crt
# N is the number of days (from now) until the cert expires
# reliers may or may not care about expiration of selfsigned,
# but to avoid possible issues it is common to use a longish period
# like 5, 10 or 20 years (roughly 1825, 3650 or 7300 days)
Para evitar que se te pregunten los campos de nombre del sujeto, que probablemente aquí no tienen sentido, puedes especificar un nombre ficticio como -subj /CN=mydkim .
Es posible que una aplicación sea lo suficientemente tonta como para utilizar PKCS12, ya que este podría desear algunas extensiones particulares en el certificado; esto abre un campo mucho más amplio porque hay alrededor de una docena de extensiones X.509 de uso común y cientos o miles de extensiones más oscuras. Si el documento de la 'aplicación' dice algo sobre las extensiones de certificado, o si obtiene un error relacionado con ellas, publique los detalles.
Una vez que tengas el certificado solo usa
openssl pkcs12 -export -in certfile -inkey privatekeyfile -out pkcs12file