Carmelo Cascone | 395b231 | 2019-06-18 17:34:16 -0700 | [diff] [blame] | 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, DES, MD5withRSA, DH keySize < 1024, \ |
| 657 | EC keySize < 224, 3DES_EDE_CBC |
| 658 | |
| 659 | # |
| 660 | # Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS) |
| 661 | # processing in JSSE implementation. |
| 662 | # |
| 663 | # In some environments, a certain algorithm may be undesirable but it |
| 664 | # cannot be disabled because of its use in legacy applications. Legacy |
| 665 | # algorithms may still be supported, but applications should not use them |
| 666 | # as the security strength of legacy algorithms are usually not strong enough |
| 667 | # in practice. |
| 668 | # |
| 669 | # During SSL/TLS security parameters negotiation, legacy algorithms will |
| 670 | # not be negotiated unless there are no other candidates. |
| 671 | # |
| 672 | # The syntax of the legacy algorithms string is described as this Java |
| 673 | # BNF-style: |
| 674 | # LegacyAlgorithms: |
| 675 | # " LegacyAlgorithm { , LegacyAlgorithm } " |
| 676 | # |
| 677 | # LegacyAlgorithm: |
| 678 | # AlgorithmName (standard JSSE algorithm name) |
| 679 | # |
| 680 | # See the specification of security property "jdk.certpath.disabledAlgorithms" |
| 681 | # for the syntax and description of the "AlgorithmName" notation. |
| 682 | # |
| 683 | # Per SSL/TLS specifications, cipher suites have the form: |
| 684 | # SSL_KeyExchangeAlg_WITH_CipherAlg_MacAlg |
| 685 | # or |
| 686 | # TLS_KeyExchangeAlg_WITH_CipherAlg_MacAlg |
| 687 | # |
| 688 | # For example, the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA uses RSA as the |
| 689 | # key exchange algorithm, AES_128_CBC (128 bits AES cipher algorithm in CBC |
| 690 | # mode) as the cipher (encryption) algorithm, and SHA-1 as the message digest |
| 691 | # algorithm for HMAC. |
| 692 | # |
| 693 | # The LegacyAlgorithm can be one of the following standard algorithm names: |
| 694 | # 1. JSSE cipher suite name, e.g., TLS_RSA_WITH_AES_128_CBC_SHA |
| 695 | # 2. JSSE key exchange algorithm name, e.g., RSA |
| 696 | # 3. JSSE cipher (encryption) algorithm name, e.g., AES_128_CBC |
| 697 | # 4. JSSE message digest algorithm name, e.g., SHA |
| 698 | # |
| 699 | # See SSL/TLS specifications and "Java Cryptography Architecture Standard |
| 700 | # Algorithm Name Documentation" for information about the algorithm names. |
| 701 | # |
| 702 | # Note: If a legacy algorithm is also restricted through the |
| 703 | # jdk.tls.disabledAlgorithms property or the |
| 704 | # java.security.AlgorithmConstraints API (See |
| 705 | # javax.net.ssl.SSLParameters.setAlgorithmConstraints()), |
| 706 | # then the algorithm is completely disabled and will not be negotiated. |
| 707 | # |
| 708 | # Note: This property is currently used by the JDK Reference implementation. |
| 709 | # It is not guaranteed to be examined and used by other implementations. |
| 710 | # There is no guarantee the property will continue to exist or be of the |
| 711 | # same syntax in future releases. |
| 712 | # |
| 713 | # Example: |
| 714 | # jdk.tls.legacyAlgorithms=DH_anon, DES_CBC, SSL_RSA_WITH_RC4_128_MD5 |
| 715 | # |
| 716 | jdk.tls.legacyAlgorithms= \ |
| 717 | K_NULL, C_NULL, M_NULL, \ |
| 718 | DH_anon, ECDH_anon, \ |
| 719 | RC4_128, RC4_40, DES_CBC, DES40_CBC, \ |
| 720 | 3DES_EDE_CBC |
| 721 | |
| 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 | # |
| 781 | # TLS key limits on symmetric cryptographic algorithms |
| 782 | # |
| 783 | # This security property sets limits on algorithms key usage in TLS 1.3. |
| 784 | # When the amount of data encrypted exceeds the algorithm value listed below, |
| 785 | # a KeyUpdate message will trigger a key change. This is for symmetric ciphers |
| 786 | # with TLS 1.3 only. |
| 787 | # |
| 788 | # The syntax for the property is described below: |
| 789 | # KeyLimits: |
| 790 | # " KeyLimit { , KeyLimit } " |
| 791 | # |
| 792 | # WeakKeyLimit: |
| 793 | # AlgorithmName Action Length |
| 794 | # |
| 795 | # AlgorithmName: |
| 796 | # A full algorithm transformation. |
| 797 | # |
| 798 | # Action: |
| 799 | # KeyUpdate |
| 800 | # |
| 801 | # Length: |
| 802 | # The amount of encrypted data in a session before the Action occurs |
| 803 | # This value may be an integer value in bytes, or as a power of two, 2^29. |
| 804 | # |
| 805 | # KeyUpdate: |
| 806 | # The TLS 1.3 KeyUpdate handshake process begins when the Length amount |
| 807 | # is fulfilled. |
| 808 | # |
| 809 | # Note: This property is currently used by OpenJDK's JSSE implementation. It |
| 810 | # is not guaranteed to be examined and used by other implementations. |
| 811 | # |
| 812 | jdk.tls.keyLimits=AES/GCM/NoPadding KeyUpdate 2^37 |
| 813 | |
| 814 | # |
| 815 | # Cryptographic Jurisdiction Policy defaults |
| 816 | # |
| 817 | # Import and export control rules on cryptographic software vary from |
| 818 | # country to country. By default, Java provides two different sets of |
| 819 | # cryptographic policy files[1]: |
| 820 | # |
| 821 | # unlimited: These policy files contain no restrictions on cryptographic |
| 822 | # strengths or algorithms |
| 823 | # |
| 824 | # limited: These policy files contain more restricted cryptographic |
| 825 | # strengths |
| 826 | # |
| 827 | # The default setting is determined by the value of the "crypto.policy" |
| 828 | # Security property below. If your country or usage requires the |
| 829 | # traditional restrictive policy, the "limited" Java cryptographic |
| 830 | # policy is still available and may be appropriate for your environment. |
| 831 | # |
| 832 | # If you have restrictions that do not fit either use case mentioned |
| 833 | # above, Java provides the capability to customize these policy files. |
| 834 | # The "crypto.policy" security property points to a subdirectory |
| 835 | # within <java-home>/conf/security/policy/ which can be customized. |
| 836 | # Please see the <java-home>/conf/security/policy/README.txt file or consult |
| 837 | # the Java Security Guide/JCA documentation for more information. |
| 838 | # |
| 839 | # YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY |
| 840 | # TO DETERMINE THE EXACT REQUIREMENTS. |
| 841 | # |
| 842 | # [1] Please note that the JCE for Java SE, including the JCE framework, |
| 843 | # cryptographic policy files, and standard JCE providers provided with |
| 844 | # the Java SE, have been reviewed and approved for export as mass market |
| 845 | # encryption item by the US Bureau of Industry and Security. |
| 846 | # |
| 847 | # Note: This property is currently used by the JDK Reference implementation. |
| 848 | # It is not guaranteed to be examined and used by other implementations. |
| 849 | # |
| 850 | crypto.policy=unlimited |
| 851 | |
| 852 | # |
| 853 | # The policy for the XML Signature secure validation mode. The mode is |
| 854 | # enabled by setting the property "org.jcp.xml.dsig.secureValidation" to |
| 855 | # true with the javax.xml.crypto.XMLCryptoContext.setProperty() method, |
| 856 | # or by running the code with a SecurityManager. |
| 857 | # |
| 858 | # Policy: |
| 859 | # Constraint {"," Constraint } |
| 860 | # Constraint: |
| 861 | # AlgConstraint | MaxTransformsConstraint | MaxReferencesConstraint | |
| 862 | # ReferenceUriSchemeConstraint | KeySizeConstraint | OtherConstraint |
| 863 | # AlgConstraint |
| 864 | # "disallowAlg" Uri |
| 865 | # MaxTransformsConstraint: |
| 866 | # "maxTransforms" Integer |
| 867 | # MaxReferencesConstraint: |
| 868 | # "maxReferences" Integer |
| 869 | # ReferenceUriSchemeConstraint: |
| 870 | # "disallowReferenceUriSchemes" String { String } |
| 871 | # KeySizeConstraint: |
| 872 | # "minKeySize" KeyAlg Integer |
| 873 | # OtherConstraint: |
| 874 | # "noDuplicateIds" | "noRetrievalMethodLoops" |
| 875 | # |
| 876 | # For AlgConstraint, Uri is the algorithm URI String that is not allowed. |
| 877 | # See the XML Signature Recommendation for more information on algorithm |
| 878 | # URI Identifiers. For KeySizeConstraint, KeyAlg is the standard algorithm |
| 879 | # name of the key type (ex: "RSA"). If the MaxTransformsConstraint, |
| 880 | # MaxReferencesConstraint or KeySizeConstraint (for the same key type) is |
| 881 | # specified more than once, only the last entry is enforced. |
| 882 | # |
| 883 | # Note: This property is currently used by the JDK Reference implementation. It |
| 884 | # is not guaranteed to be examined and used by other implementations. |
| 885 | # |
| 886 | jdk.xml.dsig.secureValidationPolicy=\ |
| 887 | disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ |
| 888 | disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ |
| 889 | disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ |
| 890 | disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ |
| 891 | maxTransforms 5,\ |
| 892 | maxReferences 30,\ |
| 893 | disallowReferenceUriSchemes file http https,\ |
| 894 | minKeySize RSA 1024,\ |
| 895 | minKeySize DSA 1024,\ |
| 896 | minKeySize EC 224,\ |
| 897 | noDuplicateIds,\ |
| 898 | noRetrievalMethodLoops |
| 899 | |
| 900 | # |
| 901 | # Serialization process-wide filter |
| 902 | # |
| 903 | # A filter, if configured, is used by java.io.ObjectInputStream during |
| 904 | # deserialization to check the contents of the stream. |
| 905 | # A filter is configured as a sequence of patterns, each pattern is either |
| 906 | # matched against the name of a class in the stream or defines a limit. |
| 907 | # Patterns are separated by ";" (semicolon). |
| 908 | # Whitespace is significant and is considered part of the pattern. |
| 909 | # |
| 910 | # If the system property jdk.serialFilter is also specified, it supersedes |
| 911 | # the security property value defined here. |
| 912 | # |
| 913 | # If a pattern includes a "=", it sets a limit. |
| 914 | # If a limit appears more than once the last value is used. |
| 915 | # Limits are checked before classes regardless of the order in the |
| 916 | # sequence of patterns. |
| 917 | # If any of the limits are exceeded, the filter status is REJECTED. |
| 918 | # |
| 919 | # maxdepth=value - the maximum depth of a graph |
| 920 | # maxrefs=value - the maximum number of internal references |
| 921 | # maxbytes=value - the maximum number of bytes in the input stream |
| 922 | # maxarray=value - the maximum array length allowed |
| 923 | # |
| 924 | # Other patterns, from left to right, match the class or package name as |
| 925 | # returned from Class.getName. |
| 926 | # If the class is an array type, the class or package to be matched is the |
| 927 | # element type. |
| 928 | # Arrays of any number of dimensions are treated the same as the element type. |
| 929 | # For example, a pattern of "!example.Foo", rejects creation of any instance or |
| 930 | # array of example.Foo. |
| 931 | # |
| 932 | # If the pattern starts with "!", the status is REJECTED if the remaining |
| 933 | # pattern is matched; otherwise the status is ALLOWED if the pattern matches. |
| 934 | # If the pattern contains "/", the non-empty prefix up to the "/" is the |
| 935 | # module name; |
| 936 | # if the module name matches the module name of the class then |
| 937 | # the remaining pattern is matched with the class name. |
| 938 | # If there is no "/", the module name is not compared. |
| 939 | # If the pattern ends with ".**" it matches any class in the package and all |
| 940 | # subpackages. |
| 941 | # If the pattern ends with ".*" it matches any class in the package. |
| 942 | # If the pattern ends with "*", it matches any class with the pattern as a |
| 943 | # prefix. |
| 944 | # If the pattern is equal to the class name, it matches. |
| 945 | # Otherwise, the status is UNDECIDED. |
| 946 | # |
| 947 | #jdk.serialFilter=pattern;pattern |
| 948 | |
| 949 | # |
| 950 | # RMI Registry Serial Filter |
| 951 | # |
| 952 | # The filter pattern uses the same format as jdk.serialFilter. |
| 953 | # This filter can override the builtin filter if additional types need to be |
| 954 | # allowed or rejected from the RMI Registry or to decrease limits but not |
| 955 | # to increase limits. |
| 956 | # If the limits (maxdepth, maxrefs, or maxbytes) are exceeded, the object is rejected. |
| 957 | # |
| 958 | # Each non-array type is allowed or rejected if it matches one of the patterns, |
| 959 | # evaluated from left to right, and is otherwise allowed. Arrays of any |
| 960 | # component type, including subarrays and arrays of primitives, are allowed. |
| 961 | # |
| 962 | # Array construction of any component type, including subarrays and arrays of |
| 963 | # primitives, are allowed unless the length is greater than the maxarray limit. |
| 964 | # The filter is applied to each array element. |
| 965 | # |
| 966 | # Note: This property is currently used by the JDK Reference implementation. |
| 967 | # It is not guaranteed to be examined and used by other implementations. |
| 968 | # |
| 969 | # The built-in filter allows subclasses of allowed classes and |
| 970 | # can approximately be represented as the pattern: |
| 971 | # |
| 972 | #sun.rmi.registry.registryFilter=\ |
| 973 | # maxarray=1000000;\ |
| 974 | # maxdepth=20;\ |
| 975 | # java.lang.String;\ |
| 976 | # java.lang.Number;\ |
| 977 | # java.lang.reflect.Proxy;\ |
| 978 | # java.rmi.Remote;\ |
| 979 | # sun.rmi.server.UnicastRef;\ |
| 980 | # sun.rmi.server.RMIClientSocketFactory;\ |
| 981 | # sun.rmi.server.RMIServerSocketFactory;\ |
| 982 | # java.rmi.activation.ActivationID;\ |
| 983 | # java.rmi.server.UID |
| 984 | # |
| 985 | # RMI Distributed Garbage Collector (DGC) Serial Filter |
| 986 | # |
| 987 | # The filter pattern uses the same format as jdk.serialFilter. |
| 988 | # This filter can override the builtin filter if additional types need to be |
| 989 | # allowed or rejected from the RMI DGC. |
| 990 | # |
| 991 | # Note: This property is currently used by the JDK Reference implementation. |
| 992 | # It is not guaranteed to be examined and used by other implementations. |
| 993 | # |
| 994 | # The builtin DGC filter can approximately be represented as the filter pattern: |
| 995 | # |
| 996 | #sun.rmi.transport.dgcFilter=\ |
| 997 | # java.rmi.server.ObjID;\ |
| 998 | # java.rmi.server.UID;\ |
| 999 | # java.rmi.dgc.VMID;\ |
| 1000 | # java.rmi.dgc.Lease;\ |
| 1001 | # maxdepth=5;maxarray=10000 |
| 1002 | |
| 1003 | # CORBA ORBIorTypeCheckRegistryFilter |
| 1004 | # Type check enhancement for ORB::string_to_object processing |
| 1005 | # |
| 1006 | # An IOR type check filter, if configured, is used by an ORB during |
| 1007 | # an ORB::string_to_object invocation to check the veracity of the type encoded |
| 1008 | # in the ior string. |
| 1009 | # |
| 1010 | # The filter pattern consists of a semi-colon separated list of class names. |
| 1011 | # The configured list contains the binary class names of the IDL interface types |
| 1012 | # corresponding to the IDL stub class to be instantiated. |
| 1013 | # As such, a filter specifies a list of IDL stub classes that will be |
| 1014 | # allowed by an ORB when an ORB::string_to_object is invoked. |
| 1015 | # It is used to specify a white list configuration of acceptable |
| 1016 | # IDL stub types which may be contained in a stringified IOR |
| 1017 | # parameter passed as input to an ORB::string_to_object method. |
| 1018 | # |
| 1019 | # Note: This property is currently used by the JDK Reference implementation. |
| 1020 | # It is not guaranteed to be examined and used by other implementations. |
| 1021 | # |
| 1022 | #com.sun.CORBA.ORBIorTypeCheckRegistryFilter=binary_class_name;binary_class_name |
| 1023 | |
| 1024 | # |
| 1025 | # JCEKS Encrypted Key Serial Filter |
| 1026 | # |
| 1027 | # This filter, if configured, is used by the JCEKS KeyStore during the |
| 1028 | # deserialization of the encrypted Key object stored inside a key entry. |
| 1029 | # If not configured or the filter result is UNDECIDED (i.e. none of the patterns |
| 1030 | # matches), the filter configured by jdk.serialFilter will be consulted. |
| 1031 | # |
| 1032 | # If the system property jceks.key.serialFilter is also specified, it supersedes |
| 1033 | # the security property value defined here. |
| 1034 | # |
| 1035 | # The filter pattern uses the same format as jdk.serialFilter. The default |
| 1036 | # pattern allows java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type, |
| 1037 | # and javax.crypto.spec.SecretKeySpec and rejects all the others. |
| 1038 | jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep;\ |
| 1039 | java.base/java.security.KeyRep$Type;java.base/javax.crypto.spec.SecretKeySpec;!* |
| 1040 | |
| 1041 | # |
| 1042 | # Enhanced exception message information |
| 1043 | # |
| 1044 | # By default, exception messages should not include potentially sensitive |
| 1045 | # information such as file names, host names, or port numbers. This property |
| 1046 | # accepts one or more comma separated values, each of which represents a |
| 1047 | # category of enhanced exception message information to enable. Values are |
| 1048 | # case-insensitive. Leading and trailing whitespaces, surrounding each value, |
| 1049 | # are ignored. Unknown values are ignored. |
| 1050 | # |
| 1051 | # NOTE: Use caution before setting this property. Setting this property |
| 1052 | # exposes sensitive information in Exceptions, which could, for example, |
| 1053 | # propagate to untrusted code or be emitted in stack traces that are |
| 1054 | # inadvertently disclosed and made accessible over a public network. |
| 1055 | # |
| 1056 | # The categories are: |
| 1057 | # |
| 1058 | # hostInfo - IOExceptions thrown by java.net.Socket and the socket types in the |
| 1059 | # java.nio.channels package will contain enhanced exception |
| 1060 | # message information |
| 1061 | # |
| 1062 | # The property setting in this file can be overridden by a system property of |
| 1063 | # the same name, with the same syntax and possible values. |
| 1064 | # |
| 1065 | #jdk.includeInExceptions=hostInfo |