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

Re: generating the TLS cert

Expand Messages
  • Robert Moskowitz
    ... 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
    Message 1 of 34 , Jan 3, 2013
    View Source
    • 0 Attachment
      On 01/03/2013 10:10 PM, Viktor Dukhovni wrote:
      > On Thu, Jan 03, 2013 at 11:05:42AM -0500, Robert Moskowitz wrote:
      >
      >> An update on creating self-signed certs.
      >>
      >> On 12/20/2012 09:32 AM, Viktor Dukhovni wrote:
      >>> On Thu, Dec 20, 2012 at 02:15:35PM +0000, Viktor Dukhovni wrote:
      >>>
      >>>> People who want a more compact recipe for a self-signed cert on
      >>>> a single SMTP server can use my "one-liner" (for machines whose
      >>>> hostname is an FQDN):
      >>>>
      >>>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
      >>>> openssl req -new \
      >>>> -newkey rsa:1280 -keyout /dev/stdout \
      >>>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
      >>>> mv "$tmp" smtpd.pem
      >>> With the "-nodes" option in most cases:
      >>>
      >>> $ tmp=$(mktemp smtpd.pem.XXXXXX) &&
      >>> openssl req -new \
      >>> -newkey rsa:1280 -nodes -keyout /dev/stdout \
      >>> -x509 -days $((365 * 10)) -subj "/CN=$(uname -n)" >> "$tmp" &&
      >>> mv "$tmp" smtpd.pem
      >>>
      >> 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.

      So I was just sharing my experience in working with the cert and what
      warnings I have been getting that are, based on the standards, correct
      warnings.

      But I think this is a pernicious problem as the localhost.crt created
      during firstboot on my Centos 6.3 system has CA=TRUE. I need to look
      into this more before I submit a bug report upstream to Redhat.
    • 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
      View Source
      • 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.