628 # from being used after the date regardless of the certificate's
629 # validity. JAR files that are signed and timestamped before the
630 # constraint date with certificates containing the disabled algorithm
631 # will not be restricted. The date is processed in the UTC timezone.
632 # This constraint can only be used once in a DisabledAlgorithm
633 # expression.
634 # Example: To deny usage of RSA 2048 bit certificates after Feb 3 2020,
635 # use the following: "RSA keySize == 2048 & denyAfter 2020-02-03"
636 #
637 # When an algorithm must satisfy more than one constraint, it must be
638 # delimited by an ampersand '&'. For example, to restrict certificates in a
639 # chain that terminate at a distribution provided trust anchor and contain
640 # RSA keys that are less than or equal to 1024 bits, add the following
641 # constraint: "RSA keySize <= 1024 & jdkCA".
642 #
643 # All DisabledAlgorithms expressions are processed in the order defined in the
644 # property. This requires lower keysize constraints to be specified
645 # before larger keysize constraints of the same algorithm. For example:
646 # "RSA keySize < 1024 & jdkCA, RSA keySize < 2048".
647 #
648 # Note: This property is currently used by Oracle's PKIX implementation. It
649 # is not guaranteed to be examined and used by other implementations.
650 #
651 # Example:
652 # jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
653 #
654 #
655 jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & denyAfter 2017-01-01, \
656 RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
657
658 # Algorithm restrictions for signed JAR files
659 #
660 # In some environments, certain algorithms or key lengths may be undesirable
661 # for signed JAR validation. For example, "MD2" is generally no longer
662 # considered to be a secure hash algorithm. This section describes the
663 # mechanism for disabling algorithms based on algorithm name and/or key length.
664 # JARs signed with any of the disabled algorithms or key sizes will be treated
665 # as unsigned.
666 #
667 # The syntax of the disabled algorithm string is described as follows:
697 # (SSL/TLS/DTLS) processing
698 #
699 # In some environments, certain algorithms or key lengths may be undesirable
700 # when using SSL/TLS/DTLS. This section describes the mechanism for disabling
701 # algorithms during SSL/TLS/DTLS security parameters negotiation, including
702 # protocol version negotiation, cipher suites selection, peer authentication
703 # and key exchange mechanisms.
704 #
705 # Disabled algorithms will not be negotiated for SSL/TLS connections, even
706 # if they are enabled explicitly in an application.
707 #
708 # For PKI-based peer authentication and key exchange mechanisms, this list
709 # of disabled algorithms will also be checked during certification path
710 # building and validation, including algorithms used in certificates, as
711 # well as revocation information such as CRLs and signed OCSP Responses.
712 # This is in addition to the jdk.certpath.disabledAlgorithms property above.
713 #
714 # See the specification of "jdk.certpath.disabledAlgorithms" for the
715 # syntax of the disabled algorithm string.
716 #
717 # Note: This property is currently used by Oracle's JSSE implementation.
718 # It is not guaranteed to be examined and used by other implementations.
719 #
720 # Example:
721 # jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
722 jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
723 EC keySize < 224
724
725 # Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS)
726 # processing in JSSE implementation.
727 #
728 # In some environments, a certain algorithm may be undesirable but it
729 # cannot be disabled because of its use in legacy applications. Legacy
730 # algorithms may still be supported, but applications should not use them
731 # as the security strength of legacy algorithms are usually not strong enough
732 # in practice.
733 #
734 # During SSL/TLS security parameters negotiation, legacy algorithms will
735 # not be negotiated unless there are no other candidates.
736 #
|
628 # from being used after the date regardless of the certificate's
629 # validity. JAR files that are signed and timestamped before the
630 # constraint date with certificates containing the disabled algorithm
631 # will not be restricted. The date is processed in the UTC timezone.
632 # This constraint can only be used once in a DisabledAlgorithm
633 # expression.
634 # Example: To deny usage of RSA 2048 bit certificates after Feb 3 2020,
635 # use the following: "RSA keySize == 2048 & denyAfter 2020-02-03"
636 #
637 # When an algorithm must satisfy more than one constraint, it must be
638 # delimited by an ampersand '&'. For example, to restrict certificates in a
639 # chain that terminate at a distribution provided trust anchor and contain
640 # RSA keys that are less than or equal to 1024 bits, add the following
641 # constraint: "RSA keySize <= 1024 & jdkCA".
642 #
643 # All DisabledAlgorithms expressions are processed in the order defined in the
644 # property. This requires lower keysize constraints to be specified
645 # before larger keysize constraints of the same algorithm. For example:
646 # "RSA keySize < 1024 & jdkCA, RSA keySize < 2048".
647 #
648 # Note: Algorithm restrictions do not apply to trusted certificates.
649 #
650 # Note: This property is currently used by Oracle's PKIX implementation. It
651 # is not guaranteed to be examined and used by other implementations.
652 #
653 # Example:
654 # jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
655 #
656 #
657 jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & denyAfter 2017-01-01, \
658 RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
659
660 # Algorithm restrictions for signed JAR files
661 #
662 # In some environments, certain algorithms or key lengths may be undesirable
663 # for signed JAR validation. For example, "MD2" is generally no longer
664 # considered to be a secure hash algorithm. This section describes the
665 # mechanism for disabling algorithms based on algorithm name and/or key length.
666 # JARs signed with any of the disabled algorithms or key sizes will be treated
667 # as unsigned.
668 #
669 # The syntax of the disabled algorithm string is described as follows:
699 # (SSL/TLS/DTLS) processing
700 #
701 # In some environments, certain algorithms or key lengths may be undesirable
702 # when using SSL/TLS/DTLS. This section describes the mechanism for disabling
703 # algorithms during SSL/TLS/DTLS security parameters negotiation, including
704 # protocol version negotiation, cipher suites selection, peer authentication
705 # and key exchange mechanisms.
706 #
707 # Disabled algorithms will not be negotiated for SSL/TLS connections, even
708 # if they are enabled explicitly in an application.
709 #
710 # For PKI-based peer authentication and key exchange mechanisms, this list
711 # of disabled algorithms will also be checked during certification path
712 # building and validation, including algorithms used in certificates, as
713 # well as revocation information such as CRLs and signed OCSP Responses.
714 # This is in addition to the jdk.certpath.disabledAlgorithms property above.
715 #
716 # See the specification of "jdk.certpath.disabledAlgorithms" for the
717 # syntax of the disabled algorithm string.
718 #
719 # Note: Algorithm restrictions do not apply to trusted certificates.
720 #
721 # Note: This property is currently used by Oracle's JSSE implementation.
722 # It is not guaranteed to be examined and used by other implementations.
723 #
724 # Example:
725 # jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
726 jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
727 EC keySize < 224
728
729 # Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS)
730 # processing in JSSE implementation.
731 #
732 # In some environments, a certain algorithm may be undesirable but it
733 # cannot be disabled because of its use in legacy applications. Legacy
734 # algorithms may still be supported, but applications should not use them
735 # as the security strength of legacy algorithms are usually not strong enough
736 # in practice.
737 #
738 # During SSL/TLS security parameters negotiation, legacy algorithms will
739 # not be negotiated unless there are no other candidates.
740 #
|