Ignorant Question On SSL Certs

Home » CentOS » Ignorant Question On SSL Certs
CentOS 9 Comments

I’m getting endless complaints about my dovecot cert,
/etc/pki/dovecot/certs/dovecot.pem which I created years ago following the dovecot instructions.

Do I really have to use a separate cert and key for dovecot?
Can I not use the “standard” cert in /etc/pki/tls/certs (and key)
from CACert.org ?

9 thoughts on - Ignorant Question On SSL Certs

  • Exact message please?

    Post the certificate only, not the private key. That is the part between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“. If you have a binary file, pipe it to ‘openssl x509 -inform DER’

    -Jason

  • Jason Pyeron wrote:

    The certificate does not apply to the given host The certificate is not signed by any trusted certificate authority

    I’ve looked at the cert and key and they look ok for what they are, a self-signed certificate and key, as created (years ago)
    following the instructions in the dovecot installation instructions.

    I’m really just asking if I cannot just use what I take to be the standard openssl certificate and key in /etc/pki/tls/
    Do I really have to create up a special cert for dovecot?

  • There’s not really a “standard” SSL certificate. Perhaps you’re referring to a “default” certificate used by the webserver?

    What I typically do is get a real, but free, SSL certificate from some place like StartSSL (www.startssl.com), and then copy the key and certificate to the location that’s specified for use by dovecot. That way, both httpd and dovecot are using the same certificate (although it’s stored in 2 different locations).

    The other thing to consider with dovecot (if you go with a third-party certificate) is that you may need to append the intermediate certificate to your server-specific certificate to properly establish the chain of trust for clients attempting to verify it.

    -Greg

  • So lets deal with this first.

    What is the hostname?

    What is the subject of the certificate [hint, I asked for the cert to be posted last time]?

    We will address this after we get more data on the problem.

    Like this: openssl x509 < /etc/pki/dovecot/certs/dovecot.pem It depends on what you mean by special and was it done properly the first time.

  • Jason Pyeron wrote:

    The cert and key in /etc/pki/tls seem to work perfectly well. My impression is that this is the standard place for CentOS and Fedora certs. IIRC, installation guides for both suggest this for certs and keys.

    Most Fedora applications that require authentication also seem to refer to this folder.

    My question is simply: Does one require a separate cert for dovecot?

  • Timothy Murphy wrote:

    This one indicates, I believe, that when you created the certs, you didn’t use the hostname of the system that you’re running now, or maybe that it wants either the FQDN, or the shortname, and it’s finding the opposite.


    This one will always be there, since you’re not a root c/a.

    mark

  • Dovecot does not care if you use the same cert for other applications.

    Your question is missing the point, others are trying to tell you that the real issue is that the cert was not created properly for the hostname that the IMAP clients are connecting to. This has nothing to do with sharing the certificate with other applications.

    I use the same cert for dovecot, postfix and apache. They are all individually happy with this single cert, but they all use the same hostname to connect (mail.example.com) and so can have the same commonname.

    Peter

  • Peter wrote:

    Thank you, that was my question.

    I don’t really care what is wrong with it, if I can do without it. I’m using the /etc/pki/tls/ cert and key in dovecot now, and they seem to work fine.

    Incidentally, I created the /etc/pki/dovecot/ cert and key years ago, and never got this flood of warning messages until recently.

    If in fact it is unnecessary to create a special cert and key for dovecot it seems to me remiss not to say this in the dovecot installation doc.