Home | History | Annotate | Download | only in security
      1 #
      2 # This is the "master security properties file".
      3 #
      4 # An alternate java.security properties file may be specified
      5 # from the command line via the system property
      6 #
      7 #    -Djava.security.properties=<URL>
      8 #
      9 # This properties file appends to the master security properties file.
     10 # If both properties files specify values for the same key, the value
     11 # from the command-line properties file is selected, as it is the last
     12 # one loaded.
     13 #
     14 # Also, if you specify
     15 #
     16 #    -Djava.security.properties==<URL> (2 equals),
     17 #
     18 # then that properties file completely overrides the master security
     19 # properties file.
     20 #
     21 # To disable the ability to specify an additional properties file from
     22 # the command line, set the key security.overridePropertiesFile
     23 # to false in the master security properties file. It is set to true
     24 # by default.
     25 
     26 # In this file, various security properties are set for use by
     27 # java.security classes. This is where users can statically register
     28 # Cryptography Package Providers ("providers" for short). The term
     29 # "provider" refers to a package or set of packages that supply a
     30 # concrete implementation of a subset of the cryptography aspects of
     31 # the Java Security API. A provider may, for example, implement one or
     32 # more digital signature algorithms or message digest algorithms.
     33 #
     34 # Each provider must implement a subclass of the Provider class.
     35 # To register a provider in this master security properties file,
     36 # specify the provider and priority in the format
     37 #
     38 #    security.provider.<n>=<provName | className>
     39 #
     40 # This declares a provider, and specifies its preference
     41 # order n. The preference order is the order in which providers are
     42 # searched for requested algorithms (when no specific provider is
     43 # requested). The order is 1-based; 1 is the most preferred, followed
     44 # by 2, and so on.
     45 #
     46 # <provName> must specify the name of the Provider as passed to its super
     47 # class java.security.Provider constructor. This is for providers loaded
     48 # through the ServiceLoader mechanism.
     49 #
     50 # <className> must specify the subclass of the Provider class whose
     51 # constructor sets the values of various properties that are required
     52 # for the Java Security API to look up the algorithms or other
     53 # facilities implemented by the provider. This is for providers loaded
     54 # through classpath.
     55 #
     56 # Note: Providers can be dynamically registered instead by calls to
     57 # either the addProvider or insertProviderAt method in the Security
     58 # class.
     59 
     60 #
     61 # List of providers and their preference orders (see above):
     62 #
     63 security.provider.1=SUN
     64 security.provider.2=SunRsaSign
     65 security.provider.3=SunEC
     66 security.provider.4=SunJSSE
     67 security.provider.5=SunJCE
     68 security.provider.6=SunJGSS
     69 security.provider.7=SunSASL
     70 security.provider.8=XMLDSig
     71 security.provider.9=SunPCSC
     72 security.provider.10=JdkLDAP
     73 security.provider.11=JdkSASL
     74 security.provider.12=SunPKCS11
     75 
     76 #
     77 # A list of preferred providers for specific algorithms. These providers will
     78 # be searched for matching algorithms before the list of registered providers.
     79 # Entries containing errors (parsing, etc) will be ignored. Use the
     80 # -Djava.security.debug=jca property to debug these errors.
     81 #
     82 # The property is a comma-separated list of serviceType.algorithm:provider
     83 # entries. The serviceType (example: "MessageDigest") is optional, and if
     84 # not specified, the algorithm applies to all service types that support it.
     85 # The algorithm is the standard algorithm name or transformation.
     86 # Transformations can be specified in their full standard name
     87 # (ex: AES/CBC/PKCS5Padding), or as partial matches (ex: AES, AES/CBC).
     88 # The provider is the name of the provider. Any provider that does not
     89 # also appear in the registered list will be ignored.
     90 #
     91 # There is a special serviceType for this property only to group a set of
     92 # algorithms together. The type is "Group" and is followed by an algorithm
     93 # keyword. Groups are to simplify and lessen the entries on the property
     94 # line. Current groups are:
     95 #   Group.SHA2 = SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256
     96 #   Group.HmacSHA2 = HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512
     97 #   Group.SHA2RSA = SHA224withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA
     98 #   Group.SHA2DSA = SHA224withDSA, SHA256withDSA, SHA384withDSA, SHA512withDSA
     99 #   Group.SHA2ECDSA = SHA224withECDSA, SHA256withECDSA, SHA384withECDSA, \
    100 #                     SHA512withECDSA
    101 #   Group.SHA3 = SHA3-224, SHA3-256, SHA3-384, SHA3-512
    102 #   Group.HmacSHA3 = HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512
    103 #
    104 # Example:
    105 #   jdk.security.provider.preferred=AES/GCM/NoPadding:SunJCE, \
    106 #         MessageDigest.SHA-256:SUN, Group.HmacSHA2:SunJCE
    107 #
    108 #jdk.security.provider.preferred=
    109 
    110 
    111 #
    112 # Sun Provider SecureRandom seed source.
    113 #
    114 # Select the primary source of seed data for the "NativePRNG", "SHA1PRNG"
    115 # and "DRBG" SecureRandom implementations in the "Sun" provider.
    116 # (Other SecureRandom implementations might also use this property.)
    117 #
    118 # On Unix-like systems (for example, Solaris/Linux/MacOS), the
    119 # "NativePRNG", "SHA1PRNG" and "DRBG" implementations obtains seed data from
    120 # special device files such as file:/dev/random.
    121 #
    122 # On Windows systems, specifying the URLs "file:/dev/random" or
    123 # "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding
    124 # mechanism for SHA1PRNG and DRBG.
    125 #
    126 # By default, an attempt is made to use the entropy gathering device
    127 # specified by the "securerandom.source" Security property.  If an
    128 # exception occurs while accessing the specified URL:
    129 #
    130 #     NativePRNG:
    131 #         a default value of /dev/random will be used.  If neither
    132 #         are available, the implementation will be disabled.
    133 #         "file" is the only currently supported protocol type.
    134 #
    135 #     SHA1PRNG and DRBG:
    136 #         the traditional system/thread activity algorithm will be used.
    137 #
    138 # The entropy gathering device can also be specified with the System
    139 # property "java.security.egd". For example:
    140 #
    141 #   % java -Djava.security.egd=file:/dev/random MainClass
    142 #
    143 # Specifying this System property will override the
    144 # "securerandom.source" Security property.
    145 #
    146 # In addition, if "file:/dev/random" or "file:/dev/urandom" is
    147 # specified, the "NativePRNG" implementation will be more preferred than
    148 # DRBG and SHA1PRNG in the Sun provider.
    149 #
    150 securerandom.source=file:/dev/random
    151 
    152 #
    153 # A list of known strong SecureRandom implementations.
    154 #
    155 # To help guide applications in selecting a suitable strong
    156 # java.security.SecureRandom implementation, Java distributions should
    157 # indicate a list of known strong implementations using the property.
    158 #
    159 # This is a comma-separated list of algorithm and/or algorithm:provider
    160 # entries.
    161 #
    162 securerandom.strongAlgorithms=NativePRNGBlocking:SUN,DRBG:SUN
    163 
    164 #
    165 # Sun provider DRBG configuration and default instantiation request.
    166 #
    167 # NIST SP 800-90Ar1 lists several DRBG mechanisms. Each can be configured
    168 # with a DRBG algorithm name, and can be instantiated with a security strength,
    169 # prediction resistance support, etc. This property defines the configuration
    170 # and the default instantiation request of "DRBG" SecureRandom implementations
    171 # in the SUN provider. (Other DRBG implementations can also use this property.)
    172 # Applications can request different instantiation parameters like security
    173 # strength, capability, personalization string using one of the
    174 # getInstance(...,SecureRandomParameters,...) methods with a
    175 # DrbgParameters.Instantiation argument, but other settings such as the
    176 # mechanism and DRBG algorithm names are not currently configurable by any API.
    177 #
    178 # Please note that the SUN implementation of DRBG always supports reseeding.
    179 #
    180 # The value of this property is a comma-separated list of all configurable
    181 # aspects. The aspects can appear in any order but the same aspect can only
    182 # appear at most once. Its BNF-style definition is:
    183 #
    184 #   Value:
    185 #     aspect { "," aspect }
    186 #
    187 #   aspect:
    188 #     mech_name | algorithm_name | strength | capability | df
    189 #
    190 #   // The DRBG mechanism to use. Default "Hash_DRBG"
    191 #   mech_name:
    192 #     "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG"
    193 #
    194 #   // The DRBG algorithm name. The "SHA-***" names are for Hash_DRBG and
    195 #   // HMAC_DRBG, default "SHA-256". The "AES-***" names are for CTR_DRBG,
    196 #   // default "AES-128" when using the limited cryptographic or "AES-256"
    197 #   // when using the unlimited.
    198 #   algorithm_name:
    199 #     "SHA-224" | "SHA-512/224" | "SHA-256" |
    200 #     "SHA-512/256" | "SHA-384" | "SHA-512" |
    201 #     "AES-128" | "AES-192" | "AES-256"
    202 #
    203 #   // Security strength requested. Default "128"
    204 #   strength:
    205 #     "112" | "128" | "192" | "256"
    206 #
    207 #   // Prediction resistance and reseeding request. Default "none"
    208 #   //  "pr_and_reseed" - Both prediction resistance and reseeding
    209 #   //                    support requested
    210 #   //  "reseed_only"   - Only reseeding support requested
    211 #   //  "none"          - Neither prediction resistance not reseeding
    212 #   //                    support requested
    213 #   pr:
    214 #     "pr_and_reseed" | "reseed_only" | "none"
    215 #
    216 #   // Whether a derivation function should be used. only applicable
    217 #   // to CTR_DRBG. Default "use_df"
    218 #   df:
    219 #     "use_df" | "no_df"
    220 #
    221 # Examples,
    222 #   securerandom.drbg.config=Hash_DRBG,SHA-224,112,none
    223 #   securerandom.drbg.config=CTR_DRBG,AES-256,192,pr_and_reseed,use_df
    224 #
    225 # The default value is an empty string, which is equivalent to
    226 #   securerandom.drbg.config=Hash_DRBG,SHA-256,128,none
    227 #
    228 securerandom.drbg.config=
    229 
    230 #
    231 # Class to instantiate as the javax.security.auth.login.Configuration
    232 # provider.
    233 #
    234 login.configuration.provider=sun.security.provider.ConfigFile
    235 
    236 #
    237 # Default login configuration file
    238 #
    239 #login.config.url.1=file:${user.home}/.java.login.config
    240 
    241 #
    242 # Class to instantiate as the system Policy. This is the name of the class
    243 # that will be used as the Policy object. The system class loader is used to
    244 # locate this class.
    245 #
    246 policy.provider=sun.security.provider.PolicyFile
    247 
    248 # The default is to have a single system-wide policy file,
    249 # and a policy file in the user's home directory.
    250 #
    251 policy.url.1=file:${java.home}/conf/security/java.policy
    252 policy.url.2=file:${user.home}/.java.policy
    253 
    254 # whether or not we expand properties in the policy file
    255 # if this is set to false, properties (${...}) will not be expanded in policy
    256 # files.
    257 #
    258 policy.expandProperties=true
    259 
    260 # whether or not we allow an extra policy to be passed on the command line
    261 # with -Djava.security.policy=somefile. Comment out this line to disable
    262 # this feature.
    263 #
    264 policy.allowSystemProperty=true
    265 
    266 # whether or not we look into the IdentityScope for trusted Identities
    267 # when encountering a 1.1 signed JAR file. If the identity is found
    268 # and is trusted, we grant it AllPermission. Note: the default policy
    269 # provider (sun.security.provider.PolicyFile) does not support this property.
    270 #
    271 policy.ignoreIdentityScope=false
    272 
    273 #
    274 # Default keystore type.
    275 #
    276 keystore.type=pkcs12
    277 
    278 #
    279 # Controls compatibility mode for JKS and PKCS12 keystore types.
    280 #
    281 # When set to 'true', both JKS and PKCS12 keystore types support loading
    282 # keystore files in either JKS or PKCS12 format. When set to 'false' the
    283 # JKS keystore type supports loading only JKS keystore files and the PKCS12
    284 # keystore type supports loading only PKCS12 keystore files.
    285 #
    286 keystore.type.compat=true
    287 
    288 #
    289 # List of comma-separated packages that start with or equal this string
    290 # will cause a security exception to be thrown when passed to the
    291 # SecurityManager::checkPackageAccess method unless the corresponding
    292 # RuntimePermission("accessClassInPackage."+package) has been granted.
    293 #
    294 package.access=sun.misc.,\
    295                sun.reflect.
    296 
    297 #
    298 # List of comma-separated packages that start with or equal this string
    299 # will cause a security exception to be thrown when passed to the
    300 # SecurityManager::checkPackageDefinition method unless the corresponding
    301 # RuntimePermission("defineClassInPackage."+package) has been granted.
    302 #
    303 # By default, none of the class loaders supplied with the JDK call
    304 # checkPackageDefinition.
    305 #
    306 package.definition=sun.misc.,\
    307                    sun.reflect.
    308 
    309 #
    310 # Determines whether this properties file can be appended to
    311 # or overridden on the command line via -Djava.security.properties
    312 #
    313 security.overridePropertiesFile=true
    314 
    315 #
    316 # Determines the default key and trust manager factory algorithms for
    317 # the javax.net.ssl package.
    318 #
    319 ssl.KeyManagerFactory.algorithm=SunX509
    320 ssl.TrustManagerFactory.algorithm=PKIX
    321 
    322 #
    323 # The Java-level namelookup cache policy for successful lookups:
    324 #
    325 # any negative value: caching forever
    326 # any positive value: the number of seconds to cache an address for
    327 # zero: do not cache
    328 #
    329 # default value is forever (FOREVER). For security reasons, this
    330 # caching is made forever when a security manager is set. When a security
    331 # manager is not set, the default behavior in this implementation
    332 # is to cache for 30 seconds.
    333 #
    334 # NOTE: setting this to anything other than the default value can have
    335 #       serious security implications. Do not set it unless
    336 #       you are sure you are not exposed to DNS spoofing attack.
    337 #
    338 #networkaddress.cache.ttl=-1
    339 
    340 # The Java-level namelookup cache policy for failed lookups:
    341 #
    342 # any negative value: cache forever
    343 # any positive value: the number of seconds to cache negative lookup results
    344 # zero: do not cache
    345 #
    346 # In some Microsoft Windows networking environments that employ
    347 # the WINS name service in addition to DNS, name service lookups
    348 # that fail may take a noticeably long time to return (approx. 5 seconds).
    349 # For this reason the default caching policy is to maintain these
    350 # results for 10 seconds.
    351 #
    352 networkaddress.cache.negative.ttl=10
    353 
    354 #
    355 # Properties to configure OCSP for certificate revocation checking
    356 #
    357 
    358 # Enable OCSP
    359 #
    360 # By default, OCSP is not used for certificate revocation checking.
    361 # This property enables the use of OCSP when set to the value "true".
    362 #
    363 # NOTE: SocketPermission is required to connect to an OCSP responder.
    364 #
    365 # Example,
    366 #   ocsp.enable=true
    367 
    368 #
    369 # Location of the OCSP responder
    370 #
    371 # By default, the location of the OCSP responder is determined implicitly
    372 # from the certificate being validated. This property explicitly specifies
    373 # the location of the OCSP responder. The property is used when the
    374 # Authority Information Access extension (defined in RFC 5280) is absent
    375 # from the certificate or when it requires overriding.
    376 #
    377 # Example,
    378 #   ocsp.responderURL=http://ocsp.example.net:80
    379 
    380 #
    381 # Subject name of the OCSP responder's certificate
    382 #
    383 # By default, the certificate of the OCSP responder is that of the issuer
    384 # of the certificate being validated. This property identifies the certificate
    385 # of the OCSP responder when the default does not apply. Its value is a string
    386 # distinguished name (defined in RFC 2253) which identifies a certificate in
    387 # the set of certificates supplied during cert path validation. In cases where
    388 # the subject name alone is not sufficient to uniquely identify the certificate
    389 # then both the "ocsp.responderCertIssuerName" and
    390 # "ocsp.responderCertSerialNumber" properties must be used instead. When this
    391 # property is set then those two properties are ignored.
    392 #
    393 # Example,
    394 #   ocsp.responderCertSubjectName=CN=OCSP Responder, O=XYZ Corp
    395 
    396 #
    397 # Issuer name of the OCSP responder's certificate
    398 #
    399 # By default, the certificate of the OCSP responder is that of the issuer
    400 # of the certificate being validated. This property identifies the certificate
    401 # of the OCSP responder when the default does not apply. Its value is a string
    402 # distinguished name (defined in RFC 2253) which identifies a certificate in
    403 # the set of certificates supplied during cert path validation. When this
    404 # property is set then the "ocsp.responderCertSerialNumber" property must also
    405 # be set. When the "ocsp.responderCertSubjectName" property is set then this
    406 # property is ignored.
    407 #
    408 # Example,
    409 #   ocsp.responderCertIssuerName=CN=Enterprise CA, O=XYZ Corp
    410 
    411 #
    412 # Serial number of the OCSP responder's certificate
    413 #
    414 # By default, the certificate of the OCSP responder is that of the issuer
    415 # of the certificate being validated. This property identifies the certificate
    416 # of the OCSP responder when the default does not apply. Its value is a string
    417 # of hexadecimal digits (colon or space separators may be present) which
    418 # identifies a certificate in the set of certificates supplied during cert path
    419 # validation. When this property is set then the "ocsp.responderCertIssuerName"
    420 # property must also be set. When the "ocsp.responderCertSubjectName" property
    421 # is set then this property is ignored.
    422 #
    423 # Example,
    424 #   ocsp.responderCertSerialNumber=2A:FF:00
    425 
    426 #
    427 # Policy for failed Kerberos KDC lookups:
    428 #
    429 # When a KDC is unavailable (network error, service failure, etc), it is
    430 # put inside a blacklist and accessed less often for future requests. The
    431 # value (case-insensitive) for this policy can be:
    432 #
    433 # tryLast
    434 #    KDCs in the blacklist are always tried after those not on the list.
    435 #
    436 # tryLess[:max_retries,timeout]
    437 #    KDCs in the blacklist are still tried by their order in the configuration,
    438 #    but with smaller max_retries and timeout values. max_retries and timeout
    439 #    are optional numerical parameters (default 1 and 5000, which means once
    440 #    and 5 seconds). Please notes that if any of the values defined here is
    441 #    more than what is defined in krb5.conf, it will be ignored.
    442 #
    443 # Whenever a KDC is detected as available, it is removed from the blacklist.
    444 # The blacklist is reset when krb5.conf is reloaded. You can add
    445 # refreshKrb5Config=true to a JAAS configuration file so that krb5.conf is
    446 # reloaded whenever a JAAS authentication is attempted.
    447 #
    448 # Example,
    449 #   krb5.kdc.bad.policy = tryLast
    450 #   krb5.kdc.bad.policy = tryLess:2,2000
    451 #
    452 krb5.kdc.bad.policy = tryLast
    453 
    454 #
    455 # Algorithm restrictions for certification path (CertPath) processing
    456 #
    457 # In some environments, certain algorithms or key lengths may be undesirable
    458 # for certification path building and validation.  For example, "MD2" is
    459 # generally no longer considered to be a secure hash algorithm.  This section
    460 # describes the mechanism for disabling algorithms based on algorithm name
    461 # and/or key length.  This includes algorithms used in certificates, as well
    462 # as revocation information such as CRLs and signed OCSP Responses.
    463 # The syntax of the disabled algorithm string is described as follows:
    464 #   DisabledAlgorithms:
    465 #       " DisabledAlgorithm { , DisabledAlgorithm } "
    466 #
    467 #   DisabledAlgorithm:
    468 #       AlgorithmName [Constraint] { '&' Constraint }
    469 #
    470 #   AlgorithmName:
    471 #       (see below)
    472 #
    473 #   Constraint:
    474 #       KeySizeConstraint | CAConstraint | DenyAfterConstraint |
    475 #       UsageConstraint
    476 #
    477 #   KeySizeConstraint:
    478 #       keySize Operator KeyLength
    479 #
    480 #   Operator:
    481 #       <= | < | == | != | >= | >
    482 #
    483 #   KeyLength:
    484 #       Integer value of the algorithm's key length in bits
    485 #
    486 #   CAConstraint:
    487 #       jdkCA
    488 #
    489 #   DenyAfterConstraint:
    490 #       denyAfter YYYY-MM-DD
    491 #
    492 #   UsageConstraint:
    493 #       usage [TLSServer] [TLSClient] [SignedJAR]
    494 #
    495 # The "AlgorithmName" is the standard algorithm name of the disabled
    496 # algorithm. See "Java Cryptography Architecture Standard Algorithm Name
    497 # Documentation" for information about Standard Algorithm Names.  Matching
    498 # is performed using a case-insensitive sub-element matching rule.  (For
    499 # example, in "SHA1withECDSA" the sub-elements are "SHA1" for hashing and
    500 # "ECDSA" for signatures.)  If the assertion "AlgorithmName" is a
    501 # sub-element of the certificate algorithm name, the algorithm will be
    502 # rejected during certification path building and validation.  For example,
    503 # the assertion algorithm name "DSA" will disable all certificate algorithms
    504 # that rely on DSA, such as NONEwithDSA, SHA1withDSA.  However, the assertion
    505 # will not disable algorithms related to "ECDSA".
    506 #
    507 # A "Constraint" defines restrictions on the keys and/or certificates for
    508 # a specified AlgorithmName:
    509 #
    510 #   KeySizeConstraint:
    511 #     keySize Operator KeyLength
    512 #       The constraint requires a key of a valid size range if the
    513 #       "AlgorithmName" is of a key algorithm.  The "KeyLength" indicates
    514 #       the key size specified in number of bits.  For example,
    515 #       "RSA keySize <= 1024" indicates that any RSA key with key size less
    516 #       than or equal to 1024 bits should be disabled, and
    517 #       "RSA keySize < 1024, RSA keySize > 2048" indicates that any RSA key
    518 #       with key size less than 1024 or greater than 2048 should be disabled.
    519 #       This constraint is only used on algorithms that have a key size.
    520 #
    521 #   CAConstraint:
    522 #     jdkCA
    523 #       This constraint prohibits the specified algorithm only if the
    524 #       algorithm is used in a certificate chain that terminates at a marked
    525 #       trust anchor in the lib/security/cacerts keystore.  If the jdkCA
    526 #       constraint is not set, then all chains using the specified algorithm
    527 #       are restricted.  jdkCA may only be used once in a DisabledAlgorithm
    528 #       expression.
    529 #       Example:  To apply this constraint to SHA-1 certificates, include
    530 #       the following:  "SHA1 jdkCA"
    531 #
    532 #   DenyAfterConstraint:
    533 #     denyAfter YYYY-MM-DD
    534 #       This constraint prohibits a certificate with the specified algorithm
    535 #       from being used after the date regardless of the certificate's
    536 #       validity.  JAR files that are signed and timestamped before the
    537 #       constraint date with certificates containing the disabled algorithm
    538 #       will not be restricted.  The date is processed in the UTC timezone.
    539 #       This constraint can only be used once in a DisabledAlgorithm
    540 #       expression.
    541 #       Example:  To deny usage of RSA 2048 bit certificates after Feb 3 2020,
    542 #       use the following:  "RSA keySize == 2048 & denyAfter 2020-02-03"
    543 #
    544 #   UsageConstraint:
    545 #     usage [TLSServer] [TLSClient] [SignedJAR]
    546 #       This constraint prohibits the specified algorithm for
    547 #       a specified usage.  This should be used when disabling an algorithm
    548 #       for all usages is not practical. 'TLSServer' restricts the algorithm
    549 #       in TLS server certificate chains when server authentication is
    550 #       performed. 'TLSClient' restricts the algorithm in TLS client
    551 #       certificate chains when client authentication is performed.
    552 #       'SignedJAR' constrains use of certificates in signed jar files.
    553 #       The usage type follows the keyword and more than one usage type can
    554 #       be specified with a whitespace delimiter.
    555 #       Example:  "SHA1 usage TLSServer TLSClient"
    556 #
    557 # When an algorithm must satisfy more than one constraint, it must be
    558 # delimited by an ampersand '&'.  For example, to restrict certificates in a
    559 # chain that terminate at a distribution provided trust anchor and contain
    560 # RSA keys that are less than or equal to 1024 bits, add the following
    561 # constraint:  "RSA keySize <= 1024 & jdkCA".
    562 #
    563 # All DisabledAlgorithms expressions are processed in the order defined in the
    564 # property.  This requires lower keysize constraints to be specified
    565 # before larger keysize constraints of the same algorithm.  For example:
    566 # "RSA keySize < 1024 & jdkCA, RSA keySize < 2048".
    567 #
    568 # Note: The algorithm restrictions do not apply to trust anchors or
    569 # self-signed certificates.
    570 #
    571 # Note: This property is currently used by Oracle's PKIX implementation. It
    572 # is not guaranteed to be examined and used by other implementations.
    573 #
    574 # Example:
    575 #   jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
    576 #
    577 #
    578 jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    579     RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
    580 
    581 #
    582 # Algorithm restrictions for signed JAR files
    583 #
    584 # In some environments, certain algorithms or key lengths may be undesirable
    585 # for signed JAR validation.  For example, "MD2" is generally no longer
    586 # considered to be a secure hash algorithm.  This section describes the
    587 # mechanism for disabling algorithms based on algorithm name and/or key length.
    588 # JARs signed with any of the disabled algorithms or key sizes will be treated
    589 # as unsigned.
    590 #
    591 # The syntax of the disabled algorithm string is described as follows:
    592 #   DisabledAlgorithms:
    593 #       " DisabledAlgorithm { , DisabledAlgorithm } "
    594 #
    595 #   DisabledAlgorithm:
    596 #       AlgorithmName [Constraint] { '&' Constraint }
    597 #
    598 #   AlgorithmName:
    599 #       (see below)
    600 #
    601 #   Constraint:
    602 #       KeySizeConstraint | DenyAfterConstraint
    603 #
    604 #   KeySizeConstraint:
    605 #       keySize Operator KeyLength
    606 #
    607 #   DenyAfterConstraint:
    608 #       denyAfter YYYY-MM-DD
    609 #
    610 #   Operator:
    611 #       <= | < | == | != | >= | >
    612 #
    613 #   KeyLength:
    614 #       Integer value of the algorithm's key length in bits
    615 #
    616 # Note: This property is currently used by the JDK Reference
    617 # implementation. It is not guaranteed to be examined and used by other
    618 # implementations.
    619 #
    620 # See "jdk.certpath.disabledAlgorithms" for syntax descriptions.
    621 #
    622 jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
    623       DSA keySize < 1024
    624 
    625 #
    626 # Algorithm restrictions for Secure Socket Layer/Transport Layer Security
    627 # (SSL/TLS/DTLS) processing
    628 #
    629 # In some environments, certain algorithms or key lengths may be undesirable
    630 # when using SSL/TLS/DTLS.  This section describes the mechanism for disabling
    631 # algorithms during SSL/TLS/DTLS security parameters negotiation, including
    632 # protocol version negotiation, cipher suites selection, peer authentication
    633 # and key exchange mechanisms.
    634 #
    635 # Disabled algorithms will not be negotiated for SSL/TLS connections, even
    636 # if they are enabled explicitly in an application.
    637 #
    638 # For PKI-based peer authentication and key exchange mechanisms, this list
    639 # of disabled algorithms will also be checked during certification path
    640 # building and validation, including algorithms used in certificates, as
    641 # well as revocation information such as CRLs and signed OCSP Responses.
    642 # This is in addition to the jdk.certpath.disabledAlgorithms property above.
    643 #
    644 # See the specification of "jdk.certpath.disabledAlgorithms" for the
    645 # syntax of the disabled algorithm string.
    646 #
    647 # Note: The algorithm restrictions do not apply to trust anchors or
    648 # self-signed certificates.
    649 #
    650 # Note: This property is currently used by the JDK Reference implementation.
    651 # It is not guaranteed to be examined and used by other implementations.
    652 #
    653 # Example:
    654 #   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
    655 jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
    656     EC keySize < 224
    657 
    658 # Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS)
    659 # processing in JSSE implementation.
    660 #
    661 # In some environments, a certain algorithm may be undesirable but it
    662 # cannot be disabled because of its use in legacy applications.  Legacy
    663 # algorithms may still be supported, but applications should not use them
    664 # as the security strength of legacy algorithms are usually not strong enough
    665 # in practice.
    666 #
    667 # During SSL/TLS security parameters negotiation, legacy algorithms will
    668 # not be negotiated unless there are no other candidates.
    669 #
    670 # The syntax of the legacy algorithms string is described as this Java
    671 # BNF-style:
    672 #   LegacyAlgorithms:
    673 #       " LegacyAlgorithm { , LegacyAlgorithm } "
    674 #
    675 #   LegacyAlgorithm:
    676 #       AlgorithmName (standard JSSE algorithm name)
    677 #
    678 # See the specification of security property "jdk.certpath.disabledAlgorithms"
    679 # for the syntax and description of the "AlgorithmName" notation.
    680 #
    681 # Per SSL/TLS specifications, cipher suites have the form:
    682 #       SSL_KeyExchangeAlg_WITH_CipherAlg_MacAlg
    683 # or
    684 #       TLS_KeyExchangeAlg_WITH_CipherAlg_MacAlg
    685 #
    686 # For example, the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA uses RSA as the
    687 # key exchange algorithm, AES_128_CBC (128 bits AES cipher algorithm in CBC
    688 # mode) as the cipher (encryption) algorithm, and SHA-1 as the message digest
    689 # algorithm for HMAC.
    690 #
    691 # The LegacyAlgorithm can be one of the following standard algorithm names:
    692 #     1. JSSE cipher suite name, e.g., TLS_RSA_WITH_AES_128_CBC_SHA
    693 #     2. JSSE key exchange algorithm name, e.g., RSA
    694 #     3. JSSE cipher (encryption) algorithm name, e.g., AES_128_CBC
    695 #     4. JSSE message digest algorithm name, e.g., SHA
    696 #
    697 # See SSL/TLS specifications and "Java Cryptography Architecture Standard
    698 # Algorithm Name Documentation" for information about the algorithm names.
    699 #
    700 # Note: If a legacy algorithm is also restricted through the
    701 # jdk.tls.disabledAlgorithms property or the
    702 # java.security.AlgorithmConstraints API (See
    703 # javax.net.ssl.SSLParameters.setAlgorithmConstraints()),
    704 # then the algorithm is completely disabled and will not be negotiated.
    705 #
    706 # Note: This property is currently used by the JDK Reference implementation.
    707 # It is not guaranteed to be examined and used by other implementations.
    708 # There is no guarantee the property will continue to exist or be of the
    709 # same syntax in future releases.
    710 #
    711 # Example:
    712 #   jdk.tls.legacyAlgorithms=DH_anon, DES_CBC, SSL_RSA_WITH_RC4_128_MD5
    713 #
    714 jdk.tls.legacyAlgorithms= \
    715         K_NULL, C_NULL, M_NULL, \
    716         DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, DH_DSS_EXPORT, \
    717         DH_RSA_EXPORT, RSA_EXPORT, \
    718         DH_anon, ECDH_anon, \
    719         RC4_128, RC4_40, DES_CBC, DES40_CBC, \
    720         3DES_EDE_CBC
    721 
    722 # The pre-defined default finite field Diffie-Hellman ephemeral (DHE)
    723 # parameters for Transport Layer Security (SSL/TLS/DTLS) processing.
    724 #
    725 # In traditional SSL/TLS/DTLS connections where finite field DHE parameters
    726 # negotiation mechanism is not used, the server offers the client group
    727 # parameters, base generator g and prime modulus p, for DHE key exchange.
    728 # It is recommended to use dynamic group parameters.  This property defines
    729 # a mechanism that allows you to specify custom group parameters.
    730 #
    731 # The syntax of this property string is described as this Java BNF-style:
    732 #   DefaultDHEParameters:
    733 #       DefinedDHEParameters { , DefinedDHEParameters }
    734 #
    735 #   DefinedDHEParameters:
    736 #       "{" DHEPrimeModulus , DHEBaseGenerator "}"
    737 #
    738 #   DHEPrimeModulus:
    739 #       HexadecimalDigits
    740 #
    741 #   DHEBaseGenerator:
    742 #       HexadecimalDigits
    743 #
    744 #   HexadecimalDigits:
    745 #       HexadecimalDigit { HexadecimalDigit }
    746 #
    747 #   HexadecimalDigit: one of
    748 #       0 1 2 3 4 5 6 7 8 9 A B C D E F a b c d e f
    749 #
    750 # Whitespace characters are ignored.
    751 #
    752 # The "DefinedDHEParameters" defines the custom group parameters, prime
    753 # modulus p and base generator g, for a particular size of prime modulus p.
    754 # The "DHEPrimeModulus" defines the hexadecimal prime modulus p, and the
    755 # "DHEBaseGenerator" defines the hexadecimal base generator g of a group
    756 # parameter.  It is recommended to use safe primes for the custom group
    757 # parameters.
    758 #
    759 # If this property is not defined or the value is empty, the underlying JSSE
    760 # provider's default group parameter is used for each connection.
    761 #
    762 # If the property value does not follow the grammar, or a particular group
    763 # parameter is not valid, the connection will fall back and use the
    764 # underlying JSSE provider's default group parameter.
    765 #
    766 # Note: This property is currently used by OpenJDK's JSSE implementation. It
    767 # is not guaranteed to be examined and used by other implementations.
    768 #
    769 # Example:
    770 #   jdk.tls.server.defaultDHEParameters=
    771 #       { \
    772 #       FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 \
    773 #       29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD \
    774 #       EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 \
    775 #       E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED \
    776 #       EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 \
    777 #       FFFFFFFF FFFFFFFF, 2}
    778 
    779 # Cryptographic Jurisdiction Policy defaults
    780 #
    781 # Due to the import control restrictions of some countries, the default
    782 # JCE policy files allow for strong but "limited" cryptographic key
    783 # lengths to be used.  If your country's cryptographic regulations allow,
    784 # the "unlimited" strength policy files can be used instead, which contain
    785 # no restrictions on cryptographic strengths.
    786 #
    787 # If your country has restrictions that don't fit either "limited" or
    788 # "unlimited", an appropriate set of policy files should be created and
    789 # configured before using this distribution.  The jurisdiction policy file
    790 # configuration must reflect the cryptographic restrictions appropriate
    791 # for your country.
    792 #
    793 # YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
    794 # TO DETERMINE THE EXACT REQUIREMENTS.
    795 #
    796 # The policy files are flat text files organized into subdirectories of
    797 # <java-home>/conf/security/policy.  Each directory contains a complete
    798 # set of policy files.
    799 #
    800 # The "crypto.policy" Security property controls the directory selection,
    801 # and thus the effective cryptographic policy.
    802 #
    803 # The default set of directories is:
    804 #
    805 #     limited | unlimited
    806 #
    807 # however other directories can be created and configured.
    808 #
    809 # Within a directory, the effective policy is the combined minimum
    810 # permissions of the grant statements in the file(s) with the filename
    811 # pattern "default_*.policy".  At least one grant is required.  For
    812 # example:
    813 #
    814 #     limited   =  Export (all) + Import (limited)  =  Limited
    815 #     unlimited =  Export (all) + Import (all)      =  Unlimited
    816 #
    817 # The effective exemption policy is the combined minimum permissions
    818 # of the grant statements in the file(s) with the filename pattern
    819 # "exempt_*.policy".  Exemption grants are optional.
    820 #
    821 #     limited   =  grants exemption permissions, by which the
    822 #                  effective policy can be circumvented.
    823 #                  e.g.  KeyRecovery/Escrow/Weakening.
    824 #
    825 # Please see the JCA documentation for additional information on these
    826 # files and formats.
    827 #
    828 # Note: This property is currently used by the JDK Reference implementation.
    829 # It is not guaranteed to be examined and used by other implementations.
    830 #
    831 crypto.policy=unlimited
    832 
    833 #
    834 # The policy for the XML Signature secure validation mode. The mode is
    835 # enabled by setting the property "org.jcp.xml.dsig.secureValidation" to
    836 # true with the javax.xml.crypto.XMLCryptoContext.setProperty() method,
    837 # or by running the code with a SecurityManager.
    838 #
    839 #   Policy:
    840 #       Constraint {"," Constraint }
    841 #   Constraint:
    842 #       AlgConstraint | MaxTransformsConstraint | MaxReferencesConstraint |
    843 #       ReferenceUriSchemeConstraint | KeySizeConstraint | OtherConstraint
    844 #   AlgConstraint
    845 #       "disallowAlg" Uri
    846 #   MaxTransformsConstraint:
    847 #       "maxTransforms" Integer
    848 #   MaxReferencesConstraint:
    849 #       "maxReferences" Integer
    850 #   ReferenceUriSchemeConstraint:
    851 #       "disallowReferenceUriSchemes" String { String }
    852 #   KeySizeConstraint:
    853 #       "minKeySize" KeyAlg Integer
    854 #   OtherConstraint:
    855 #       "noDuplicateIds" | "noRetrievalMethodLoops"
    856 #
    857 # For AlgConstraint, Uri is the algorithm URI String that is not allowed.
    858 # See the XML Signature Recommendation for more information on algorithm
    859 # URI Identifiers. For KeySizeConstraint, KeyAlg is the standard algorithm
    860 # name of the key type (ex: "RSA"). If the MaxTransformsConstraint,
    861 # MaxReferencesConstraint or KeySizeConstraint (for the same key type) is
    862 # specified more than once, only the last entry is enforced.
    863 #
    864 # Note: This property is currently used by the JDK Reference implementation. It
    865 # is not guaranteed to be examined and used by other implementations.
    866 #
    867 jdk.xml.dsig.secureValidationPolicy=\
    868     disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    869     disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    870     disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    871     disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    872     maxTransforms 5,\
    873     maxReferences 30,\
    874     disallowReferenceUriSchemes file http https,\
    875     minKeySize RSA 1024,\
    876     minKeySize DSA 1024,\
    877     noDuplicateIds,\
    878     noRetrievalMethodLoops
    879 
    880 #
    881 # Serialization process-wide filter
    882 #
    883 # A filter, if configured, is used by java.io.ObjectInputStream during
    884 # deserialization to check the contents of the stream.
    885 # A filter is configured as a sequence of patterns, each pattern is either
    886 # matched against the name of a class in the stream or defines a limit.
    887 # Patterns are separated by ";" (semicolon).
    888 # Whitespace is significant and is considered part of the pattern.
    889 #
    890 # If a pattern includes a "=", it sets a limit.
    891 # If a limit appears more than once the last value is used.
    892 # Limits are checked before classes regardless of the order in the
    893 # sequence of patterns.
    894 # If any of the limits are exceeded, the filter status is REJECTED.
    895 #
    896 #   maxdepth=value - the maximum depth of a graph
    897 #   maxrefs=value  - the maximum number of internal references
    898 #   maxbytes=value - the maximum number of bytes in the input stream
    899 #   maxarray=value - the maximum array length allowed
    900 #
    901 # Other patterns, from left to right, match the class or package name as
    902 # returned from Class.getName.
    903 # If the class is an array type, the class or package to be matched is the
    904 # element type.
    905 # Arrays of any number of dimensions are treated the same as the element type.
    906 # For example, a pattern of "!example.Foo", rejects creation of any instance or
    907 # array of example.Foo.
    908 #
    909 # If the pattern starts with "!", the status is REJECTED if the remaining
    910 # pattern is matched; otherwise the status is ALLOWED if the pattern matches.
    911 # If the pattern contains "/", the non-empty prefix up to the "/" is the
    912 # module name;
    913 #   if the module name matches the module name of the class then
    914 #   the remaining pattern is matched with the class name.
    915 #   If there is no "/", the module name is not compared.
    916 # If the pattern ends with ".**" it matches any class in the package and all
    917 # subpackages.
    918 # If the pattern ends with ".*" it matches any class in the package.
    919 # If the pattern ends with "*", it matches any class with the pattern as a
    920 # prefix.
    921 # If the pattern is equal to the class name, it matches.
    922 # Otherwise, the status is UNDECIDED.
    923 #
    924 #jdk.serialFilter=pattern;pattern
    925 
    926 #
    927 # RMI Registry Serial Filter
    928 #
    929 # The filter pattern uses the same format as jdk.serialFilter.
    930 # This filter can override the builtin filter if additional types need to be
    931 # allowed or rejected from the RMI Registry.
    932 #
    933 # Note: This property is currently used by the JDK Reference implementation.
    934 # It is not guaranteed to be examined and used by other implementations.
    935 #
    936 #sun.rmi.registry.registryFilter=pattern;pattern
    937 #
    938 # RMI Distributed Garbage Collector (DGC) Serial Filter
    939 #
    940 # The filter pattern uses the same format as jdk.serialFilter.
    941 # This filter can override the builtin filter if additional types need to be
    942 # allowed or rejected from the RMI DGC.
    943 #
    944 # Note: This property is currently used by the JDK Reference implementation.
    945 # It is not guaranteed to be examined and used by other implementations.
    946 #
    947 # The builtin DGC filter can approximately be represented as the filter pattern:
    948 #
    949 #sun.rmi.transport.dgcFilter=\
    950 #    java.rmi.server.ObjID;\
    951 #    java.rmi.server.UID;\
    952 #    java.rmi.dgc.VMID;\
    953 #    java.rmi.dgc.Lease;\
    954 #    maxdepth=5;maxarray=10000
    955