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