Loading ...
Sorry, an error occurred while loading the content.

Re: generating the TLS cert

Expand Messages
  • Robert Moskowitz
    ... By some definitions of wrong :) You may not have attended the same sort of PKI policy meetings that I lived through! But since this is in large measure
    Message 1 of 34 , Jan 4, 2013
    • 0 Attachment
      On 01/04/2013 11:38 AM, Viktor Dukhovni wrote:
      > On Fri, Jan 04, 2013 at 12:57:00AM -0500, Robert Moskowitz wrote:
      >
      >>>> I was noticing an error in /var/log/httpd/ssl_error_log about the
      >>>> cert having basicConstraints: CA=TRUE
      >>> If some HTTP server does not like self-signed SSL certs with CA=TRUE,
      >>> that's its own problem. Postfix will not force you to jump through
      >>> such pointless hoops.
      >> It was a warning. More likely it would be the clients that would
      >> object. Postfix may be happy with such a cert, but some other MTA
      >> or client might not accept such a cert from Postfix.
      >>
      >> One of the IETF mantras is "be conservative in what you send and
      >> liberal in what you accept". So a client SHOULD accept this, but
      >> not MUST accept it. A server MAY send it, but SHOULD avoid it.
      > There is nothing wrong with "CA:true" in a self-signed SSL certificate.

      By some definitions of 'wrong' :)

      You may not have attended the same sort of PKI policy meetings that I
      lived through! But since this is in large measure a policy issue, we
      will leave it there.

      > If, however, your default "openssl.cnf" adds "CA:true", and you'd rather
      > not have it present, the "one liner" can be updated slightly to:
      >
      > # tmp=$(mktemp smptpd.pem.XXXXXX) &&
      > openssl req -new \
      > -newkey rsa:1280 -keyout "$tmp" -nodes \
      > -x509 -subj "/CN=$(uname -n)" -days $((365 * 10)) -extensions usr_cert \
      > -out /dev/stdout >> "$tmp" &&
      > mv "$tmp" smtpd.pem
      >
      > provided that same "openssl.cnf" has the usual "usr_cert" section
      > as well as the inconvenient "v3_ca" section with:
      >
      > basicConstraints = CA:true
      >
      > or
      >
      > basicConstraints = critical,CA:true
      >
      I will test with user_cert over v3_req that I learned about over on the
      OpenSSL list. See how they compare.

      Thank you.
    • Viktor Dukhovni
      ... What meetings you happened to attend is of no consequence. ... It is usr_cert , not user_cert . The difference in the resulting extensions is: v3_req:
      Message 34 of 34 , Jan 4, 2013
      • 0 Attachment
        On Fri, Jan 04, 2013 at 12:30:50PM -0500, Robert Moskowitz wrote:

        > >There is nothing wrong with "CA:true" in a self-signed SSL certificate.
        >
        > By some definitions of 'wrong' :)
        >
        > You may not have attended the same sort of PKI policy meetings that
        > I lived through! But since this is in large measure a policy issue,
        > we will leave it there.

        What meetings you happened to attend is of no consequence.

        > I will test with user_cert over v3_req that I learned about over on
        > the OpenSSL list. See how they compare.

        It is "usr_cert", not "user_cert". The difference in the resulting
        extensions is:

        v3_req:
        X509v3 Basic Constraints:
        CA:FALSE
        X509v3 Key Usage:
        Digital Signature, Non Repudiation, Key Encipherment

        usr_cert:
        X509v3 Basic Constraints:
        CA:FALSE
        Netscape Comment:
        OpenSSL Generated Certificate
        X509v3 Subject Key Identifier:
        AD:3C:28:E3:E5:B5:F3:0A:5C:63:AB:08:15:4E:1C:42:A3:D5:83:E6
        X509v3 Authority Key Identifier:
        keyid:AD:3C:28:E3:E5:B5:F3:0A:5C:63:AB:08:15:4E:1C:42:A3:D5:83:E6

        default (v3_ca):
        X509v3 Subject Key Identifier:
        EC:1C:FE:EE:26:9E:09:44:8C:75:5C:F7:1E:38:32:4A:FA:93:FA:E6
        X509v3 Authority Key Identifier:
        keyid:EC:1C:FE:EE:26:9E:09:44:8C:75:5C:F7:1E:38:32:4A:FA:93:FA:E6
        X509v3 Basic Constraints:
        CA:TRUE

        Perhaps of the three "v3_req" is the closest to a sensible set of
        extensions for an endpoint certificate.

        --
        Viktor.
      Your message has been successfully submitted and would be delivered to recipients shortly.