1. 29 10月, 2018 9 次提交
  2. 28 10月, 2018 1 次提交
  3. 27 10月, 2018 1 次提交
    • F
      Support GeneralSubtrees with minimum = 0 · c23e497d
      Fraser Tweedale 提交于
      The Name Constraints extension contains GeneralSubtree values
      indicating included or excluded subtrees.  It is defined as:
      
        GeneralSubtree ::= SEQUENCE {
          base                    GeneralName,
          minimum         [0]     BaseDistance DEFAULT 0,
          maximum         [1]     BaseDistance OPTIONAL }
      
      RFC 5280 further specifies:
      
        Within this profile, the minimum and maximum fields are not used with
        any name forms, thus, the minimum MUST be zero, and maximum MUST be
        absent.
      
      Because the minimum fields has DEFAULT 0, and certificates should be
      encoded using DER, the situation where minimum = 0 occurs in a
      certificate should not arise.  Nevertheless, it does arise.  For
      example, I have seen certificates issued by Microsoft programs that
      contain GeneralSubtree values encoded thus.
      
      Enhance the Name Constraints matching routine to handle the case
      where minimum is specified.  If present, it must be zero.  The
      maximum field remains prohibited.
      Reviewed-by: NPaul Yang <yang.yang@baishancloud.com>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7039)
      c23e497d
  4. 26 10月, 2018 8 次提交
  5. 25 10月, 2018 1 次提交
    • R
      Windows: Produce a static version of the public libraries, always · b3023ced
      Richard Levitte 提交于
      When building shared libraries on Windows, we had a clash between
      'libcrypto.lib' the static routine library and 'libcrypto.lib' the
      import library.
      
      We now change it so the static versions of our libraries get '_static'
      appended to their names.  These will never get installed, but can
      still be used for our internal purposes, such as internal tests.
      
      When building non-shared, the renaming mechanism doesn't come into
      play.  In that case, the static libraries 'libcrypto.lib' and
      'libssl.lib' are installed, just as always.
      
      Fixes #7492
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7496)
      b3023ced
  6. 23 10月, 2018 2 次提交
  7. 22 10月, 2018 1 次提交
    • D
      RAND_add(): fix heap corruption in error path · 5b4cb385
      Dr. Matthias St. Pierre 提交于
      This bug was introduced by #7382 which enhanced RAND_add() to
      accept large buffer sizes. As a consequence, RAND_add() now fails
      for buffer sizes less than 32 bytes (i.e. less than 256 bits).
      In addition, rand_drbg_get_entropy() forgets to reset the attached
      drbg->pool in the case of an error, which leads to the heap corruption.
      
      The problem occurred with RAND_load_file(), which reads the file in
      chunks of 1024 bytes each. If the size of the final chunk is less than
      32 bytes, then RAND_add() fails, whence RAND_load_file() fails
      silently for buffer sizes n = k * 1024 + r with r = 1,...,31.
      
      This commit fixes the heap corruption only. The other issues will
      be addressed in a separate pull request.
      
      Thanks to Gisle Vanem for reporting this issue.
      
      Fixes #7449
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7455)
      5b4cb385
  8. 21 10月, 2018 1 次提交
  9. 19 10月, 2018 9 次提交
  10. 18 10月, 2018 2 次提交
    • V
      Apply self-imposed path length also to root CAs · dc5831da
      Viktor Dukhovni 提交于
      Also, some readers of the code find starting the count at 1 for EE
      cert confusing (since RFC5280 counts only non-self-issued intermediate
      CAs, but we also counted the leaf).  Therefore, never count the EE
      cert, and adjust the path length comparison accordinly.  This may
      be more clear to the reader.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      dc5831da
    • V
      Only CA certificates can be self-issued · ed422a2d
      Viktor Dukhovni 提交于
      At the bottom of https://tools.ietf.org/html/rfc5280#page-12 and
      top of https://tools.ietf.org/html/rfc5280#page-13 (last paragraph
      of above https://tools.ietf.org/html/rfc5280#section-3.3), we see:
      
         This specification covers two classes of certificates: CA
         certificates and end entity certificates.  CA certificates may be
         further divided into three classes: cross-certificates, self-issued
         certificates, and self-signed certificates.  Cross-certificates are
         CA certificates in which the issuer and subject are different
         entities.  Cross-certificates describe a trust relationship between
         the two CAs.  Self-issued certificates are CA certificates in which
         the issuer and subject are the same entity.  Self-issued certificates
         are generated to support changes in policy or operations.  Self-
         signed certificates are self-issued certificates where the digital
         signature may be verified by the public key bound into the
         certificate.  Self-signed certificates are used to convey a public
         key for use to begin certification paths.  End entity certificates
         are issued to subjects that are not authorized to issue certificates.
      
      that the term "self-issued" is only applicable to CAs, not end-entity
      certificates.  In https://tools.ietf.org/html/rfc5280#section-4.2.1.9
      the description of path length constraints says:
      
         The pathLenConstraint field is meaningful only if the cA boolean is
         asserted and the key usage extension, if present, asserts the
         keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
         maximum number of non-self-issued intermediate certificates that may
         follow this certificate in a valid certification path.  (Note: The
         last certificate in the certification path is not an intermediate
         certificate, and is not included in this limit.  Usually, the last
         certificate is an end entity certificate, but it can be a CA
         certificate.)
      
      This makes it clear that exclusion of self-issued certificates from
      the path length count applies only to some *intermediate* CA
      certificates.  A leaf certificate whether it has identical issuer
      and subject or whether it is a CA or not is never part of the
      intermediate certificate count.  The handling of all leaf certificates
      must be the same, in the case of our code to post-increment the
      path count by 1, so that we ultimately reach a non-self-issued
      intermediate it will be the first one (not zeroth) in the chain
      of intermediates.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      ed422a2d
  11. 17 10月, 2018 5 次提交