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# If this properties file fails to load, the JDK implementation will throw 27# an unspecified error when initializing the java.security.Security class. 28# Properties in this file are typically parsed only once. If any of the 29# properties are modified, applications should be restarted to ensure the 30# changes are properly reflected. 31 32# In this file, various security properties are set for use by 33# java.security classes. This is where users can statically register 34# Cryptography Package Providers ("providers" for short). The term 35# "provider" refers to a package or set of packages that supply a 36# concrete implementation of a subset of the cryptography aspects of 37# the Java Security API. A provider may, for example, implement one or 38# more digital signature algorithms or message digest algorithms. 39# 40# Each provider must implement a subclass of the Provider class. 41# To register a provider in this master security properties file, 42# specify the provider and priority in the format 43# 44# security.provider.<n>=<provName | className> 45# 46# This declares a provider, and specifies its preference 47# order n. The preference order is the order in which providers are 48# searched for requested algorithms (when no specific provider is 49# requested). The order is 1-based; 1 is the most preferred, followed 50# by 2, and so on. 51# 52# <provName> must specify the name of the Provider as passed to its super 53# class java.security.Provider constructor. This is for providers loaded 54# through the ServiceLoader mechanism. 55# 56# <className> must specify the subclass of the Provider class whose 57# constructor sets the values of various properties that are required 58# for the Java Security API to look up the algorithms or other 59# facilities implemented by the provider. This is for providers loaded 60# through classpath. 61# 62# Note: Providers can be dynamically registered instead by calls to 63# either the addProvider or insertProviderAt method in the Security 64# class. 65 66# 67# List of providers and their preference orders (see above): 68# 69security.provider.1=SUN 70security.provider.2=SunRsaSign 71security.provider.3=SunEC 72security.provider.4=SunJSSE 73security.provider.5=SunJCE 74security.provider.6=SunJGSS 75security.provider.7=SunSASL 76security.provider.8=XMLDSig 77security.provider.9=SunPCSC 78security.provider.10=JdkLDAP 79security.provider.11=JdkSASL 80security.provider.12=SunPKCS11 81 82# 83# A list of preferred providers for specific algorithms. These providers will 84# be searched for matching algorithms before the list of registered providers. 85# Entries containing errors (parsing, etc) will be ignored. Use the 86# -Djava.security.debug=jca property to debug these errors. 87# 88# The property is a comma-separated list of serviceType.algorithm:provider 89# entries. The serviceType (example: "MessageDigest") is optional, and if 90# not specified, the algorithm applies to all service types that support it. 91# The algorithm is the standard algorithm name or transformation. 92# Transformations can be specified in their full standard name 93# (ex: AES/CBC/PKCS5Padding), or as partial matches (ex: AES, AES/CBC). 94# The provider is the name of the provider. Any provider that does not 95# also appear in the registered list will be ignored. 96# 97# There is a special serviceType for this property only to group a set of 98# algorithms together. The type is "Group" and is followed by an algorithm 99# keyword. Groups are to simplify and lessen the entries on the property 100# line. Current groups are: 101# Group.SHA2 = SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 102# Group.HmacSHA2 = HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512 103# Group.SHA2RSA = SHA224withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA 104# Group.SHA2DSA = SHA224withDSA, SHA256withDSA, SHA384withDSA, SHA512withDSA 105# Group.SHA2ECDSA = SHA224withECDSA, SHA256withECDSA, SHA384withECDSA, \ 106# SHA512withECDSA 107# Group.SHA3 = SHA3-224, SHA3-256, SHA3-384, SHA3-512 108# Group.HmacSHA3 = HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512 109# 110# Example: 111# jdk.security.provider.preferred=AES/GCM/NoPadding:SunJCE, \ 112# MessageDigest.SHA-256:SUN, Group.HmacSHA2:SunJCE 113# 114#jdk.security.provider.preferred= 115 116 117# 118# Sun Provider SecureRandom seed source. 119# 120# Select the primary source of seed data for the "NativePRNG", "SHA1PRNG" 121# and "DRBG" SecureRandom implementations in the "Sun" provider. 122# (Other SecureRandom implementations might also use this property.) 123# 124# On Unix-like systems (for example, Linux/MacOS), the 125# "NativePRNG", "SHA1PRNG" and "DRBG" implementations obtains seed data from 126# special device files such as file:/dev/random. 127# 128# On Windows systems, specifying the URLs "file:/dev/random" or 129# "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding 130# mechanism for SHA1PRNG and DRBG. 131# 132# By default, an attempt is made to use the entropy gathering device 133# specified by the "securerandom.source" Security property. If an 134# exception occurs while accessing the specified URL: 135# 136# NativePRNG: 137# a default value of /dev/random will be used. If neither 138# are available, the implementation will be disabled. 139# "file" is the only currently supported protocol type. 140# 141# SHA1PRNG and DRBG: 142# the traditional system/thread activity algorithm will be used. 143# 144# The entropy gathering device can also be specified with the System 145# property "java.security.egd". For example: 146# 147# % java -Djava.security.egd=file:/dev/random MainClass 148# 149# Specifying this System property will override the 150# "securerandom.source" Security property. 151# 152# In addition, if "file:/dev/random" or "file:/dev/urandom" is 153# specified, the "NativePRNG" implementation will be more preferred than 154# DRBG and SHA1PRNG in the Sun provider. 155# 156securerandom.source=file:/dev/random 157 158# 159# A list of known strong SecureRandom implementations. 160# 161# To help guide applications in selecting a suitable strong 162# java.security.SecureRandom implementation, Java distributions should 163# indicate a list of known strong implementations using the property. 164# 165# This is a comma-separated list of algorithm and/or algorithm:provider 166# entries. 167# 168securerandom.strongAlgorithms=NativePRNGBlocking:SUN,DRBG:SUN 169 170# 171# Sun provider DRBG configuration and default instantiation request. 172# 173# NIST SP 800-90Ar1 lists several DRBG mechanisms. Each can be configured 174# with a DRBG algorithm name, and can be instantiated with a security strength, 175# prediction resistance support, etc. This property defines the configuration 176# and the default instantiation request of "DRBG" SecureRandom implementations 177# in the SUN provider. (Other DRBG implementations can also use this property.) 178# Applications can request different instantiation parameters like security 179# strength, capability, personalization string using one of the 180# getInstance(...,SecureRandomParameters,...) methods with a 181# DrbgParameters.Instantiation argument, but other settings such as the 182# mechanism and DRBG algorithm names are not currently configurable by any API. 183# 184# Please note that the SUN implementation of DRBG always supports reseeding. 185# 186# The value of this property is a comma-separated list of all configurable 187# aspects. The aspects can appear in any order but the same aspect can only 188# appear at most once. Its BNF-style definition is: 189# 190# Value: 191# aspect { "," aspect } 192# 193# aspect: 194# mech_name | algorithm_name | strength | capability | df 195# 196# // The DRBG mechanism to use. Default "Hash_DRBG" 197# mech_name: 198# "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" 199# 200# // The DRBG algorithm name. The "SHA-***" names are for Hash_DRBG and 201# // HMAC_DRBG, default "SHA-256". The "AES-***" names are for CTR_DRBG, 202# // default "AES-128" when using the limited cryptographic or "AES-256" 203# // when using the unlimited. 204# algorithm_name: 205# "SHA-224" | "SHA-512/224" | "SHA-256" | 206# "SHA-512/256" | "SHA-384" | "SHA-512" | 207# "AES-128" | "AES-192" | "AES-256" 208# 209# // Security strength requested. Default "128" 210# strength: 211# "112" | "128" | "192" | "256" 212# 213# // Prediction resistance and reseeding request. Default "none" 214# // "pr_and_reseed" - Both prediction resistance and reseeding 215# // support requested 216# // "reseed_only" - Only reseeding support requested 217# // "none" - Neither prediction resistance not reseeding 218# // support requested 219# pr: 220# "pr_and_reseed" | "reseed_only" | "none" 221# 222# // Whether a derivation function should be used. only applicable 223# // to CTR_DRBG. Default "use_df" 224# df: 225# "use_df" | "no_df" 226# 227# Examples, 228# securerandom.drbg.config=Hash_DRBG,SHA-224,112,none 229# securerandom.drbg.config=CTR_DRBG,AES-256,192,pr_and_reseed,use_df 230# 231# The default value is an empty string, which is equivalent to 232# securerandom.drbg.config=Hash_DRBG,SHA-256,128,none 233# 234securerandom.drbg.config= 235 236# 237# Class to instantiate as the javax.security.auth.login.Configuration 238# provider. 239# 240login.configuration.provider=sun.security.provider.ConfigFile 241 242# 243# Default login configuration file 244# 245#login.config.url.1=file:${user.home}/.java.login.config 246 247# 248# Class to instantiate as the system Policy. This is the name of the class 249# that will be used as the Policy object. The system class loader is used to 250# locate this class. 251# 252policy.provider=sun.security.provider.PolicyFile 253 254# The default is to have a single system-wide policy file, 255# and a policy file in the user's home directory. 256# 257policy.url.1=file:${java.home}/conf/security/java.policy 258policy.url.2=file:${user.home}/.java.policy 259 260# Controls whether or not properties are expanded in policy and login 261# configuration files. If set to false, properties (${...}) will not 262# be expanded in policy and login configuration files. If commented out or 263# set to an empty string, the default value is "false" for policy files and 264# "true" for login configuration files. 265# 266policy.expandProperties=true 267 268# Controls whether or not an extra policy or login configuration file is 269# allowed to be passed on the command line with -Djava.security.policy=somefile 270# or -Djava.security.auth.login.config=somefile. If commented out or set to 271# an empty string, the default value is "false". 272# 273policy.allowSystemProperty=true 274 275# whether or not we look into the IdentityScope for trusted Identities 276# when encountering a 1.1 signed JAR file. If the identity is found 277# and is trusted, we grant it AllPermission. Note: the default policy 278# provider (sun.security.provider.PolicyFile) does not support this property. 279# 280policy.ignoreIdentityScope=false 281 282# 283# Default keystore type. 284# 285keystore.type=pkcs12 286 287# 288# Controls compatibility mode for JKS and PKCS12 keystore types. 289# 290# When set to 'true', both JKS and PKCS12 keystore types support loading 291# keystore files in either JKS or PKCS12 format. When set to 'false' the 292# JKS keystore type supports loading only JKS keystore files and the PKCS12 293# keystore type supports loading only PKCS12 keystore files. 294# 295keystore.type.compat=true 296 297# 298# List of comma-separated packages that start with or equal this string 299# will cause a security exception to be thrown when passed to the 300# SecurityManager::checkPackageAccess method unless the corresponding 301# RuntimePermission("accessClassInPackage."+package) has been granted. 302# 303package.access=sun.misc.,\ 304 sun.reflect. 305 306# 307# List of comma-separated packages that start with or equal this string 308# will cause a security exception to be thrown when passed to the 309# SecurityManager::checkPackageDefinition method unless the corresponding 310# RuntimePermission("defineClassInPackage."+package) has been granted. 311# 312# By default, none of the class loaders supplied with the JDK call 313# checkPackageDefinition. 314# 315package.definition=sun.misc.,\ 316 sun.reflect. 317 318# 319# Determines whether this properties file can be appended to 320# or overridden on the command line via -Djava.security.properties 321# 322security.overridePropertiesFile=true 323 324# 325# Determines the default key and trust manager factory algorithms for 326# the javax.net.ssl package. 327# 328ssl.KeyManagerFactory.algorithm=SunX509 329ssl.TrustManagerFactory.algorithm=PKIX 330 331# 332# The Java-level namelookup cache policy for successful lookups: 333# 334# any negative value: caching forever 335# any positive value: the number of seconds to cache an address for 336# zero: do not cache 337# 338# default value is forever (FOREVER). For security reasons, this 339# caching is made forever when a security manager is set. When a security 340# manager is not set, the default behavior in this implementation 341# is to cache for 30 seconds. 342# 343# NOTE: setting this to anything other than the default value can have 344# serious security implications. Do not set it unless 345# you are sure you are not exposed to DNS spoofing attack. 346# 347#networkaddress.cache.ttl=-1 348 349# 350# The Java-level namelookup cache stale policy: 351# 352# any positive value: the number of seconds to use the stale names 353# zero: do not use stale names 354# negative values are ignored 355# 356# default value is 0 (NEVER). 357# 358#networkaddress.cache.stale.ttl=0 359 360# The Java-level namelookup cache policy for failed lookups: 361# 362# any negative value: cache forever 363# any positive value: the number of seconds to cache negative lookup results 364# zero: do not cache 365# 366# In some Microsoft Windows networking environments that employ 367# the WINS name service in addition to DNS, name service lookups 368# that fail may take a noticeably long time to return (approx. 5 seconds). 369# For this reason the default caching policy is to maintain these 370# results for 10 seconds. 371# 372networkaddress.cache.negative.ttl=10 373 374# 375# Properties to configure OCSP for certificate revocation checking 376# 377 378# Enable OCSP 379# 380# By default, OCSP is not used for certificate revocation checking. 381# This property enables the use of OCSP when set to the value "true". 382# 383# NOTE: SocketPermission is required to connect to an OCSP responder. 384# 385# Example, 386# ocsp.enable=true 387 388# 389# Location of the OCSP responder 390# 391# By default, the location of the OCSP responder is determined implicitly 392# from the certificate being validated. This property explicitly specifies 393# the location of the OCSP responder. The property is used when the 394# Authority Information Access extension (defined in RFC 5280) is absent 395# from the certificate or when it requires overriding. 396# 397# Example, 398# ocsp.responderURL=http://ocsp.example.net:80 399 400# 401# Subject name of the OCSP responder's certificate 402# 403# By default, the certificate of the OCSP responder is that of the issuer 404# of the certificate being validated. This property identifies the certificate 405# of the OCSP responder when the default does not apply. Its value is a string 406# distinguished name (defined in RFC 2253) which identifies a certificate in 407# the set of certificates supplied during cert path validation. In cases where 408# the subject name alone is not sufficient to uniquely identify the certificate 409# then both the "ocsp.responderCertIssuerName" and 410# "ocsp.responderCertSerialNumber" properties must be used instead. When this 411# property is set then those two properties are ignored. 412# 413# Example, 414# ocsp.responderCertSubjectName=CN=OCSP Responder, O=XYZ Corp 415 416# 417# Issuer name of the OCSP responder's certificate 418# 419# By default, the certificate of the OCSP responder is that of the issuer 420# of the certificate being validated. This property identifies the certificate 421# of the OCSP responder when the default does not apply. Its value is a string 422# distinguished name (defined in RFC 2253) which identifies a certificate in 423# the set of certificates supplied during cert path validation. When this 424# property is set then the "ocsp.responderCertSerialNumber" property must also 425# be set. When the "ocsp.responderCertSubjectName" property is set then this 426# property is ignored. 427# 428# Example, 429# ocsp.responderCertIssuerName=CN=Enterprise CA, O=XYZ Corp 430 431# 432# Serial number of the OCSP responder's certificate 433# 434# By default, the certificate of the OCSP responder is that of the issuer 435# of the certificate being validated. This property identifies the certificate 436# of the OCSP responder when the default does not apply. Its value is a string 437# of hexadecimal digits (colon or space separators may be present) which 438# identifies a certificate in the set of certificates supplied during cert path 439# validation. When this property is set then the "ocsp.responderCertIssuerName" 440# property must also be set. When the "ocsp.responderCertSubjectName" property 441# is set then this property is ignored. 442# 443# Example, 444# ocsp.responderCertSerialNumber=2A:FF:00 445 446# 447# Policy for failed Kerberos KDC lookups: 448# 449# When a KDC is unavailable (network error, service failure, etc), it is 450# put inside a secondary list and accessed less often for future requests. The 451# value (case-insensitive) for this policy can be: 452# 453# tryLast 454# KDCs in the secondary list are always tried after those not on the list. 455# 456# tryLess[:max_retries,timeout] 457# KDCs in the secondary list are still tried by their order in the 458# configuration, but with smaller max_retries and timeout values. 459# max_retries and timeout are optional numerical parameters (default 1 and 460# 5000, which means once and 5 seconds). Please note that if any of the 461# values defined here are more than what is defined in krb5.conf, it will be 462# ignored. 463# 464# Whenever a KDC is detected as available, it is removed from the secondary 465# list. The secondary list is reset when krb5.conf is reloaded. You can add 466# refreshKrb5Config=true to a JAAS configuration file so that krb5.conf is 467# reloaded whenever a JAAS authentication is attempted. 468# 469# Example, 470# krb5.kdc.bad.policy = tryLast 471# krb5.kdc.bad.policy = tryLess:2,2000 472# 473krb5.kdc.bad.policy = tryLast 474 475# 476# Kerberos cross-realm referrals (RFC 6806) 477# 478# OpenJDK's Kerberos client supports cross-realm referrals as defined in 479# RFC 6806. This allows to setup more dynamic environments in which clients 480# do not need to know in advance how to reach the realm of a target principal 481# (either a user or service). 482# 483# When a client issues an AS or a TGS request, the "canonicalize" option 484# is set to announce support of this feature. A KDC server may fulfill the 485# request or reply referring the client to a different one. If referred, 486# the client will issue a new request and the cycle repeats. 487# 488# In addition to referrals, the "canonicalize" option allows the KDC server 489# to change the client name in response to an AS request. For security reasons, 490# RFC 6806 (section 11) FAST scheme is enforced. 491# 492# Disable Kerberos cross-realm referrals. Value may be overwritten with a 493# System property (-Dsun.security.krb5.disableReferrals). 494sun.security.krb5.disableReferrals=false 495 496# Maximum number of AS or TGS referrals to avoid infinite loops. Value may 497# be overwritten with a System property (-Dsun.security.krb5.maxReferrals). 498sun.security.krb5.maxReferrals=5 499 500# 501# This property contains a list of disabled EC Named Curves that can be included 502# in the jdk.[tls|certpath|jar].disabledAlgorithms properties. To include this 503# list in any of the disabledAlgorithms properties, add the property name as 504# an entry. 505#jdk.disabled.namedCurves= 506 507# 508# Algorithm restrictions for certification path (CertPath) processing 509# 510# In some environments, certain algorithms or key lengths may be undesirable 511# for certification path building and validation. For example, "MD2" is 512# generally no longer considered to be a secure hash algorithm. This section 513# describes the mechanism for disabling algorithms based on algorithm name 514# and/or key length. This includes algorithms used in certificates, as well 515# as revocation information such as CRLs and signed OCSP Responses. 516# The syntax of the disabled algorithm string is described as follows: 517# DisabledAlgorithms: 518# " DisabledAlgorithm { , DisabledAlgorithm } " 519# 520# DisabledAlgorithm: 521# AlgorithmName [Constraint] { '&' Constraint } | IncludeProperty 522# 523# AlgorithmName: 524# (see below) 525# 526# Constraint: 527# KeySizeConstraint | CAConstraint | DenyAfterConstraint | 528# UsageConstraint 529# 530# KeySizeConstraint: 531# keySize Operator KeyLength 532# 533# Operator: 534# <= | < | == | != | >= | > 535# 536# KeyLength: 537# Integer value of the algorithm's key length in bits 538# 539# CAConstraint: 540# jdkCA 541# 542# DenyAfterConstraint: 543# denyAfter YYYY-MM-DD 544# 545# UsageConstraint: 546# usage [TLSServer] [TLSClient] [SignedJAR] 547# 548# IncludeProperty: 549# include <security property> 550# 551# The "AlgorithmName" is the standard algorithm name of the disabled 552# algorithm. See the Java Security Standard Algorithm Names Specification 553# for information about Standard Algorithm Names. Matching is 554# performed using a case-insensitive sub-element matching rule. (For 555# example, in "SHA1withECDSA" the sub-elements are "SHA1" for hashing and 556# "ECDSA" for signatures.) If the assertion "AlgorithmName" is a 557# sub-element of the certificate algorithm name, the algorithm will be 558# rejected during certification path building and validation. For example, 559# the assertion algorithm name "DSA" will disable all certificate algorithms 560# that rely on DSA, such as NONEwithDSA, SHA1withDSA. However, the assertion 561# will not disable algorithms related to "ECDSA". 562# 563# The "IncludeProperty" allows a implementation-defined security property that 564# can be included in the disabledAlgorithms properties. These properties are 565# to help manage common actions easier across multiple disabledAlgorithm 566# properties. 567# There is one defined security property: jdk.disabled.namedCurves 568# See the property for more specific details. 569# 570# 571# A "Constraint" defines restrictions on the keys and/or certificates for 572# a specified AlgorithmName: 573# 574# KeySizeConstraint: 575# keySize Operator KeyLength 576# The constraint requires a key of a valid size range if the 577# "AlgorithmName" is of a key algorithm. The "KeyLength" indicates 578# the key size specified in number of bits. For example, 579# "RSA keySize <= 1024" indicates that any RSA key with key size less 580# than or equal to 1024 bits should be disabled, and 581# "RSA keySize < 1024, RSA keySize > 2048" indicates that any RSA key 582# with key size less than 1024 or greater than 2048 should be disabled. 583# This constraint is only used on algorithms that have a key size. 584# 585# CAConstraint: 586# jdkCA 587# This constraint prohibits the specified algorithm only if the 588# algorithm is used in a certificate chain that terminates at a marked 589# trust anchor in the lib/security/cacerts keystore. If the jdkCA 590# constraint is not set, then all chains using the specified algorithm 591# are restricted. jdkCA may only be used once in a DisabledAlgorithm 592# expression. 593# Example: To apply this constraint to SHA-1 certificates, include 594# the following: "SHA1 jdkCA" 595# 596# DenyAfterConstraint: 597# denyAfter YYYY-MM-DD 598# This constraint prohibits a certificate with the specified algorithm 599# from being used after the date regardless of the certificate's 600# validity. JAR files that are signed and timestamped before the 601# constraint date with certificates containing the disabled algorithm 602# will not be restricted. The date is processed in the UTC timezone. 603# This constraint can only be used once in a DisabledAlgorithm 604# expression. 605# Example: To deny usage of RSA 2048 bit certificates after Feb 3 2020, 606# use the following: "RSA keySize == 2048 & denyAfter 2020-02-03" 607# 608# UsageConstraint: 609# usage [TLSServer] [TLSClient] [SignedJAR] 610# This constraint prohibits the specified algorithm for 611# a specified usage. This should be used when disabling an algorithm 612# for all usages is not practical. 'TLSServer' restricts the algorithm 613# in TLS server certificate chains when server authentication is 614# performed. 'TLSClient' restricts the algorithm in TLS client 615# certificate chains when client authentication is performed. 616# 'SignedJAR' constrains use of certificates in signed jar files. 617# The usage type follows the keyword and more than one usage type can 618# be specified with a whitespace delimiter. 619# Example: "SHA1 usage TLSServer TLSClient" 620# 621# When an algorithm must satisfy more than one constraint, it must be 622# delimited by an ampersand '&'. For example, to restrict certificates in a 623# chain that terminate at a distribution provided trust anchor and contain 624# RSA keys that are less than or equal to 1024 bits, add the following 625# constraint: "RSA keySize <= 1024 & jdkCA". 626# 627# All DisabledAlgorithms expressions are processed in the order defined in the 628# property. This requires lower keysize constraints to be specified 629# before larger keysize constraints of the same algorithm. For example: 630# "RSA keySize < 1024 & jdkCA, RSA keySize < 2048". 631# 632# Note: The algorithm restrictions do not apply to trust anchors or 633# self-signed certificates. 634# 635# Note: This property is currently used by Oracle's PKIX implementation. It 636# is not guaranteed to be examined and used by other implementations. 637# 638# Example: 639# jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048 640# 641# 642jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ 643 RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \ 644 SHA1 usage SignedJAR & denyAfter 2019-01-01 645 646# 647# Legacy cryptographic algorithms and key lengths. 648# 649# In some environments, a certain algorithm or key length may be undesirable. 650# 651# Tools such as keytool and jarsigner may emit warnings when these legacy 652# algorithms are used. See the man pages for those tools for more information. 653# 654# The syntax is the same as the "jdk.certpath.disabledAlgorithms" and 655# "jdk.jar.disabledAlgorithms" security properties. 656# 657# Note: This property is currently used by the JDK Reference 658# implementation. It is not guaranteed to be examined and used by other 659# implementations. 660 661jdk.security.legacyAlgorithms=SHA1, \ 662 RSA keySize < 2048, DSA keySize < 2048, \ 663 DES, DESede, MD5, RC2, ARCFOUR 664 665# 666# Algorithm restrictions for signed JAR files 667# 668# In some environments, certain algorithms or key lengths may be undesirable 669# for signed JAR validation. For example, "MD2" is generally no longer 670# considered to be a secure hash algorithm. This section describes the 671# mechanism for disabling algorithms based on algorithm name and/or key length. 672# JARs signed with any of the disabled algorithms or key sizes will be treated 673# as unsigned. 674# 675# The syntax of the disabled algorithm string is described as follows: 676# DisabledAlgorithms: 677# " DisabledAlgorithm { , DisabledAlgorithm } " 678# 679# DisabledAlgorithm: 680# AlgorithmName [Constraint] { '&' Constraint } 681# 682# AlgorithmName: 683# (see below) 684# 685# Constraint: 686# KeySizeConstraint | DenyAfterConstraint 687# 688# KeySizeConstraint: 689# keySize Operator KeyLength 690# 691# DenyAfterConstraint: 692# denyAfter YYYY-MM-DD 693# 694# Operator: 695# <= | < | == | != | >= | > 696# 697# KeyLength: 698# Integer value of the algorithm's key length in bits 699# 700# Note: This property is currently used by the JDK Reference 701# implementation. It is not guaranteed to be examined and used by other 702# implementations. 703# 704# See "jdk.certpath.disabledAlgorithms" for syntax descriptions. 705# 706jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \ 707 DSA keySize < 1024, SHA1 denyAfter 2019-01-01 708 709# 710# Disabled message digest algorithms for use with plaintext 711# HTTP Digest authentication (java.net.HttpURLConnection). 712# This includes HTTPS Digest authentication to proxies. 713# This may be overridden by setting the networking (or system) 714# property "http.auth.digest.reEnabledAlgorithms" to a comma 715# separated list of algorithms to be allowed. 716# 717http.auth.digest.disabledAlgorithms = MD5, SHA-1 718 719# 720# Algorithm restrictions for Secure Socket Layer/Transport Layer Security 721# (SSL/TLS/DTLS) processing 722# 723# In some environments, certain algorithms or key lengths may be undesirable 724# when using SSL/TLS/DTLS. This section describes the mechanism for disabling 725# algorithms during SSL/TLS/DTLS security parameters negotiation, including 726# protocol version negotiation, cipher suites selection, named groups 727# selection, signature schemes selection, peer authentication and key 728# exchange mechanisms. 729# 730# Disabled algorithms will not be negotiated for SSL/TLS connections, even 731# if they are enabled explicitly in an application. 732# 733# For PKI-based peer authentication and key exchange mechanisms, this list 734# of disabled algorithms will also be checked during certification path 735# building and validation, including algorithms used in certificates, as 736# well as revocation information such as CRLs and signed OCSP Responses. 737# This is in addition to the jdk.certpath.disabledAlgorithms property above. 738# 739# See the specification of "jdk.certpath.disabledAlgorithms" for the 740# syntax of the disabled algorithm string. 741# 742# Note: The algorithm restrictions do not apply to trust anchors or 743# self-signed certificates. 744# 745# Note: This property is currently used by the JDK Reference implementation. 746# It is not guaranteed to be examined and used by other implementations. 747# 748# Example: 749# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, \ 750# rsa_pkcs1_sha1, secp224r1 751jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, DTLSv1.0, RC4, DES, \ 752 MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \ 753 ECDH 754 755# 756# Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS) 757# processing in JSSE implementation. 758# 759# In some environments, a certain algorithm may be undesirable but it 760# cannot be disabled because of its use in legacy applications. Legacy 761# algorithms may still be supported, but applications should not use them 762# as the security strength of legacy algorithms are usually not strong enough 763# in practice. 764# 765# During SSL/TLS security parameters negotiation, legacy algorithms will 766# not be negotiated unless there are no other candidates. 767# 768# The syntax of the legacy algorithms string is described as this Java 769# BNF-style: 770# LegacyAlgorithms: 771# " LegacyAlgorithm { , LegacyAlgorithm } " 772# 773# LegacyAlgorithm: 774# AlgorithmName (standard JSSE algorithm name) 775# 776# See the specification of security property "jdk.certpath.disabledAlgorithms" 777# for the syntax and description of the "AlgorithmName" notation. 778# 779# Per SSL/TLS specifications, cipher suites have the form: 780# SSL_KeyExchangeAlg_WITH_CipherAlg_MacAlg 781# or 782# TLS_KeyExchangeAlg_WITH_CipherAlg_MacAlg 783# 784# For example, the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA uses RSA as the 785# key exchange algorithm, AES_128_CBC (128 bits AES cipher algorithm in CBC 786# mode) as the cipher (encryption) algorithm, and SHA-1 as the message digest 787# algorithm for HMAC. 788# 789# The LegacyAlgorithm can be one of the following standard algorithm names: 790# 1. JSSE cipher suite name, e.g., TLS_RSA_WITH_AES_128_CBC_SHA 791# 2. JSSE key exchange algorithm name, e.g., RSA 792# 3. JSSE cipher (encryption) algorithm name, e.g., AES_128_CBC 793# 4. JSSE message digest algorithm name, e.g., SHA 794# 795# See SSL/TLS specifications and the Java Security Standard Algorithm Names 796# Specification for information about the algorithm names. 797# 798# Note: If a legacy algorithm is also restricted through the 799# jdk.tls.disabledAlgorithms property or the 800# java.security.AlgorithmConstraints API (See 801# javax.net.ssl.SSLParameters.setAlgorithmConstraints()), 802# then the algorithm is completely disabled and will not be negotiated. 803# 804# Note: This property is currently used by the JDK Reference implementation. 805# It is not guaranteed to be examined and used by other implementations. 806# There is no guarantee the property will continue to exist or be of the 807# same syntax in future releases. 808# 809# Example: 810# jdk.tls.legacyAlgorithms=DH_anon, DES_CBC, SSL_RSA_WITH_RC4_128_MD5 811# 812jdk.tls.legacyAlgorithms=NULL, anon, RC4, DES, 3DES_EDE_CBC 813 814# 815# The pre-defined default finite field Diffie-Hellman ephemeral (DHE) 816# parameters for Transport Layer Security (SSL/TLS/DTLS) processing. 817# 818# In traditional SSL/TLS/DTLS connections where finite field DHE parameters 819# negotiation mechanism is not used, the server offers the client group 820# parameters, base generator g and prime modulus p, for DHE key exchange. 821# It is recommended to use dynamic group parameters. This property defines 822# a mechanism that allows you to specify custom group parameters. 823# 824# The syntax of this property string is described as this Java BNF-style: 825# DefaultDHEParameters: 826# DefinedDHEParameters { , DefinedDHEParameters } 827# 828# DefinedDHEParameters: 829# "{" DHEPrimeModulus , DHEBaseGenerator "}" 830# 831# DHEPrimeModulus: 832# HexadecimalDigits 833# 834# DHEBaseGenerator: 835# HexadecimalDigits 836# 837# HexadecimalDigits: 838# HexadecimalDigit { HexadecimalDigit } 839# 840# HexadecimalDigit: one of 841# 0 1 2 3 4 5 6 7 8 9 A B C D E F a b c d e f 842# 843# Whitespace characters are ignored. 844# 845# The "DefinedDHEParameters" defines the custom group parameters, prime 846# modulus p and base generator g, for a particular size of prime modulus p. 847# The "DHEPrimeModulus" defines the hexadecimal prime modulus p, and the 848# "DHEBaseGenerator" defines the hexadecimal base generator g of a group 849# parameter. It is recommended to use safe primes for the custom group 850# parameters. 851# 852# If this property is not defined or the value is empty, the underlying JSSE 853# provider's default group parameter is used for each connection. 854# 855# If the property value does not follow the grammar, or a particular group 856# parameter is not valid, the connection will fall back and use the 857# underlying JSSE provider's default group parameter. 858# 859# Note: This property is currently used by OpenJDK's JSSE implementation. It 860# is not guaranteed to be examined and used by other implementations. 861# 862# Example: 863# jdk.tls.server.defaultDHEParameters= 864# { \ 865# FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 \ 866# 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD \ 867# EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 \ 868# E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED \ 869# EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 \ 870# FFFFFFFF FFFFFFFF, 2} 871 872# 873# TLS key limits on symmetric cryptographic algorithms 874# 875# This security property sets limits on algorithms key usage in TLS 1.3. 876# When the amount of data encrypted exceeds the algorithm value listed below, 877# a KeyUpdate message will trigger a key change. This is for symmetric ciphers 878# with TLS 1.3 only. 879# 880# The syntax for the property is described below: 881# KeyLimits: 882# " KeyLimit { , KeyLimit } " 883# 884# WeakKeyLimit: 885# AlgorithmName Action Length 886# 887# AlgorithmName: 888# A full algorithm transformation. 889# 890# Action: 891# KeyUpdate 892# 893# Length: 894# The amount of encrypted data in a session before the Action occurs 895# This value may be an integer value in bytes, or as a power of two, 2^29. 896# 897# KeyUpdate: 898# The TLS 1.3 KeyUpdate handshake process begins when the Length amount 899# is fulfilled. 900# 901# Note: This property is currently used by OpenJDK's JSSE implementation. It 902# is not guaranteed to be examined and used by other implementations. 903# 904jdk.tls.keyLimits=AES/GCM/NoPadding KeyUpdate 2^37, \ 905 ChaCha20-Poly1305 KeyUpdate 2^37 906 907# 908# Cryptographic Jurisdiction Policy defaults 909# 910# Import and export control rules on cryptographic software vary from 911# country to country. By default, Java provides two different sets of 912# cryptographic policy files[1]: 913# 914# unlimited: These policy files contain no restrictions on cryptographic 915# strengths or algorithms 916# 917# limited: These policy files contain more restricted cryptographic 918# strengths 919# 920# The default setting is determined by the value of the "crypto.policy" 921# Security property below. If your country or usage requires the 922# traditional restrictive policy, the "limited" Java cryptographic 923# policy is still available and may be appropriate for your environment. 924# 925# If you have restrictions that do not fit either use case mentioned 926# above, Java provides the capability to customize these policy files. 927# The "crypto.policy" security property points to a subdirectory 928# within <java-home>/conf/security/policy/ which can be customized. 929# Please see the <java-home>/conf/security/policy/README.txt file or consult 930# the Java Security Guide/JCA documentation for more information. 931# 932# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY 933# TO DETERMINE THE EXACT REQUIREMENTS. 934# 935# [1] Please note that the JCE for Java SE, including the JCE framework, 936# cryptographic policy files, and standard JCE providers provided with 937# the Java SE, have been reviewed and approved for export as mass market 938# encryption item by the US Bureau of Industry and Security. 939# 940# Note: This property is currently used by the JDK Reference implementation. 941# It is not guaranteed to be examined and used by other implementations. 942# 943crypto.policy=unlimited 944 945# 946# The policy for the XML Signature secure validation mode. Validation of 947# XML Signatures that violate any of these constraints will fail. 948# The mode can be enabled or disabled by setting the property 949# "org.jcp.xml.dsig.secureValidation" to Boolean.TRUE or Boolean.FALSE with 950# the javax.xml.crypto.XMLCryptoContext.setProperty() method, or by setting 951# the system property "org.jcp.xml.dsig.secureValidation" to "true" or 952# "false". Any other value for the system property is also treated as "false". 953# If the system property is set, it supersedes the XMLCryptoContext property 954# value. 955# 956# The secure validation mode is enabled by default. 957# 958# Policy: 959# Constraint {"," Constraint } 960# Constraint: 961# AlgConstraint | MaxTransformsConstraint | MaxReferencesConstraint | 962# ReferenceUriSchemeConstraint | KeySizeConstraint | OtherConstraint 963# AlgConstraint 964# "disallowAlg" Uri 965# MaxTransformsConstraint: 966# "maxTransforms" Integer 967# MaxReferencesConstraint: 968# "maxReferences" Integer 969# ReferenceUriSchemeConstraint: 970# "disallowReferenceUriSchemes" String { String } 971# KeySizeConstraint: 972# "minKeySize" KeyAlg Integer 973# OtherConstraint: 974# "noDuplicateIds" | "noRetrievalMethodLoops" 975# 976# For AlgConstraint, Uri is the algorithm URI String that is not allowed. 977# See the XML Signature Recommendation for more information on algorithm 978# URI Identifiers. For KeySizeConstraint, KeyAlg is the standard algorithm 979# name of the key type (ex: "RSA"). If the MaxTransformsConstraint, 980# MaxReferencesConstraint or KeySizeConstraint (for the same key type) is 981# specified more than once, only the last entry is enforced. 982# 983# Note: This property is currently used by the JDK Reference implementation. 984# It is not guaranteed to be examined and used by other implementations. 985# 986jdk.xml.dsig.secureValidationPolicy=\ 987 disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ 988 disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ 989 disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ 990 disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ 991 disallowAlg http://www.w3.org/2000/09/xmldsig#sha1,\ 992 disallowAlg http://www.w3.org/2000/09/xmldsig#dsa-sha1,\ 993 disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1,\ 994 disallowAlg http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1,\ 995 disallowAlg http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1,\ 996 maxTransforms 5,\ 997 maxReferences 30,\ 998 disallowReferenceUriSchemes file http https,\ 999 minKeySize RSA 1024,\ 1000 minKeySize DSA 1024,\ 1001 minKeySize EC 224,\ 1002 noDuplicateIds,\ 1003 noRetrievalMethodLoops 1004 1005# 1006# Support for the here() function 1007# 1008# This security property determines whether the here() XPath function is 1009# supported in XML Signature generation and verification. 1010# 1011# If this property is set to false, the here() function is not supported. 1012# Generating an XML Signature that uses the here() function will throw an 1013# XMLSignatureException. Validating an existing XML Signature that uses the 1014# here() function will also throw an XMLSignatureException. 1015# 1016# The default value for this property is true. 1017# 1018# Note: This property is currently used by the JDK Reference implementation. 1019# It is not guaranteed to be examined and used by other implementations. 1020# 1021#jdk.xml.dsig.hereFunctionSupported=true 1022 1023# 1024# Deserialization JVM-wide filter factory 1025# 1026# A filter factory class name is used to configure the JVM-wide filter factory. 1027# The class must be public, must have a public zero-argument constructor, implement the 1028# java.util.function.BinaryOperator<java.io.ObjectInputFilter> interface, provide its 1029# implementation and be accessible via the application class loader. 1030# A builtin filter factory is used if no filter factory is defined. 1031# See java.io.ObjectInputFilter.Config for more information. 1032# 1033# If the system property jdk.serialFilterFactory is also specified, it supersedes 1034# the security property value defined here. 1035# 1036#jdk.serialFilterFactory=<classname> 1037 1038# 1039# Deserialization JVM-wide filter 1040# 1041# A filter, if configured, is used by the filter factory to provide the filter used by 1042# java.io.ObjectInputStream during deserialization to check the contents of the stream. 1043# A filter is configured as a sequence of patterns, each pattern is either 1044# matched against the name of a class in the stream or defines a limit. 1045# Patterns are separated by ";" (semicolon). 1046# Whitespace is significant and is considered part of the pattern. 1047# 1048# If the system property jdk.serialFilter is also specified, it supersedes 1049# the security property value defined here. 1050# 1051# If a pattern includes a "=", it sets a limit. 1052# If a limit appears more than once the last value is used. 1053# Limits are checked before classes regardless of the order in the 1054# sequence of patterns. 1055# If any of the limits are exceeded, the filter status is REJECTED. 1056# 1057# maxdepth=value - the maximum depth of a graph 1058# maxrefs=value - the maximum number of internal references 1059# maxbytes=value - the maximum number of bytes in the input stream 1060# maxarray=value - the maximum array length allowed 1061# 1062# Other patterns, from left to right, match the class or package name as 1063# returned from Class.getName. 1064# If the class is an array type, the class or package to be matched is the 1065# element type. 1066# Arrays of any number of dimensions are treated the same as the element type. 1067# For example, a pattern of "!example.Foo", rejects creation of any instance or 1068# array of example.Foo. 1069# 1070# If the pattern starts with "!", the status is REJECTED if the remaining 1071# pattern is matched; otherwise the status is ALLOWED if the pattern matches. 1072# If the pattern contains "/", the non-empty prefix up to the "/" is the 1073# module name; 1074# if the module name matches the module name of the class then 1075# the remaining pattern is matched with the class name. 1076# If there is no "/", the module name is not compared. 1077# If the pattern ends with ".**" it matches any class in the package and all 1078# subpackages. 1079# If the pattern ends with ".*" it matches any class in the package. 1080# If the pattern ends with "*", it matches any class with the pattern as a 1081# prefix. 1082# If the pattern is equal to the class name, it matches. 1083# Otherwise, the status is UNDECIDED. 1084# 1085#jdk.serialFilter=pattern;pattern 1086 1087# 1088# RMI Registry Serial Filter 1089# 1090# The filter pattern uses the same format as jdk.serialFilter. 1091# This filter can override the builtin filter if additional types need to be 1092# allowed or rejected from the RMI Registry or to decrease limits but not 1093# to increase limits. 1094# If the limits (maxdepth, maxrefs, or maxbytes) are exceeded, the object is rejected. 1095# 1096# Each non-array type is allowed or rejected if it matches one of the patterns, 1097# evaluated from left to right, and is otherwise allowed. Arrays of any 1098# component type, including subarrays and arrays of primitives, are allowed. 1099# 1100# Array construction of any component type, including subarrays and arrays of 1101# primitives, are allowed unless the length is greater than the maxarray limit. 1102# The filter is applied to each array element. 1103# 1104# Note: This property is currently used by the JDK Reference implementation. 1105# It is not guaranteed to be examined and used by other implementations. 1106# 1107# The built-in filter allows subclasses of allowed classes and 1108# can approximately be represented as the pattern: 1109# 1110#sun.rmi.registry.registryFilter=\ 1111# maxarray=1000000;\ 1112# maxdepth=20;\ 1113# java.lang.String;\ 1114# java.lang.Number;\ 1115# java.lang.reflect.Proxy;\ 1116# java.rmi.Remote;\ 1117# sun.rmi.server.UnicastRef;\ 1118# sun.rmi.server.RMIClientSocketFactory;\ 1119# sun.rmi.server.RMIServerSocketFactory;\ 1120# java.rmi.server.UID 1121# 1122# RMI Distributed Garbage Collector (DGC) Serial Filter 1123# 1124# The filter pattern uses the same format as jdk.serialFilter. 1125# This filter can override the builtin filter if additional types need to be 1126# allowed or rejected from the RMI DGC. 1127# 1128# Note: This property is currently used by the JDK Reference implementation. 1129# It is not guaranteed to be examined and used by other implementations. 1130# 1131# The builtin DGC filter can approximately be represented as the filter pattern: 1132# 1133#sun.rmi.transport.dgcFilter=\ 1134# java.rmi.server.ObjID;\ 1135# java.rmi.server.UID;\ 1136# java.rmi.dgc.VMID;\ 1137# java.rmi.dgc.Lease;\ 1138# maxdepth=5;maxarray=10000 1139 1140# 1141# JCEKS Encrypted Key Serial Filter 1142# 1143# This filter, if configured, is used by the JCEKS KeyStore during the 1144# deserialization of the encrypted Key object stored inside a key entry. 1145# If not configured or the filter result is UNDECIDED (i.e. none of the patterns 1146# matches), the filter configured by jdk.serialFilter will be consulted. 1147# 1148# If the system property jceks.key.serialFilter is also specified, it supersedes 1149# the security property value defined here. 1150# 1151# The filter pattern uses the same format as jdk.serialFilter. The default 1152# pattern allows java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type, 1153# and javax.crypto.spec.SecretKeySpec and rejects all the others. 1154jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep;\ 1155 java.base/java.security.KeyRep$Type;java.base/javax.crypto.spec.SecretKeySpec;!* 1156 1157# The iteration count used for password-based encryption (PBE) in JCEKS 1158# keystores. Values in the range 10000 to 5000000 are considered valid. 1159# If the value is out of this range, or is not a number, or is unspecified; 1160# a default of 200000 is used. 1161# 1162# If the system property jdk.jceks.iterationCount is also specified, it 1163# supersedes the security property value defined here. 1164# 1165#jdk.jceks.iterationCount = 200000 1166 1167# 1168# PKCS12 KeyStore properties 1169# 1170# The following properties, if configured, are used by the PKCS12 KeyStore 1171# implementation during the creation of a new keystore. Several of the 1172# properties may also be used when modifying an existing keystore. The 1173# properties can be overridden by a KeyStore API that specifies its own 1174# algorithms and parameters. 1175# 1176# If an existing PKCS12 keystore is loaded and then stored, the algorithm and 1177# parameter used to generate the existing Mac will be reused. If the existing 1178# keystore does not have a Mac, no Mac will be created while storing. If there 1179# is at least one certificate in the existing keystore, the algorithm and 1180# parameters used to encrypt the last certificate in the existing keystore will 1181# be reused to encrypt all certificates while storing. If the last certificate 1182# in the existing keystore is not encrypted, all certificates will be stored 1183# unencrypted. If there is no certificate in the existing keystore, any newly 1184# added certificate will be encrypted (or stored unencrypted if algorithm 1185# value is "NONE") using the "keystore.pkcs12.certProtectionAlgorithm" and 1186# "keystore.pkcs12.certPbeIterationCount" values defined here. Existing private 1187# and secret key(s) are not changed. Newly set private and secret key(s) will 1188# be encrypted using the "keystore.pkcs12.keyProtectionAlgorithm" and 1189# "keystore.pkcs12.keyPbeIterationCount" values defined here. 1190# 1191# In order to apply new algorithms and parameters to all entries in an 1192# existing keystore, one can create a new keystore and add entries in the 1193# existing keystore into the new keystore. This can be achieved by calling the 1194# "keytool -importkeystore" command. 1195# 1196# If a system property of the same name is also specified, it supersedes the 1197# security property value defined here. 1198# 1199# If the property is set to an illegal value, an iteration count that is not 1200# a positive integer, or an unknown algorithm name, an exception will be thrown 1201# when the property is used. If the property is not set or empty, a default 1202# value will be used. 1203# 1204# Some PKCS12 tools and libraries may not support algorithms based on PBES2 1205# and AES. To create a PKCS12 keystore which they can load, set the system 1206# property "keystore.pkcs12.legacy" which overrides the values of the properties 1207# defined below with legacy algorithms. Setting this system property (which can 1208# only be enabled and has no value) is equivalent to 1209# 1210# -Dkeystore.pkcs12.certProtectionAlgorithm=PBEWithSHA1AndRC2_40 1211# -Dkeystore.pkcs12.keyProtectionAlgorithm=PBEWithSHA1AndDESede 1212# -Dkeystore.pkcs12.macAlgorithm=HmacPBESHA1 1213# -Dkeystore.pkcs12.certPbeIterationCount=50000 1214# -Dkeystore.pkcs12.keyPbeIterationCount=50000 1215# -Dkeystore.pkcs12.macIterationCount=100000 1216# 1217# Also, you can downgrade an existing PKCS12 keystore created with stronger 1218# algorithms to legacy algorithms with 1219# 1220# keytool -J-Dkeystore.pkcs12.legacy -importkeystore -srckeystore ks -destkeystore ks 1221# 1222# This system property should be used at your own risk. 1223# 1224# Note: These properties are currently used by the JDK Reference implementation. 1225# They are not guaranteed to be examined and used by other implementations. 1226 1227# The algorithm used to encrypt a certificate. This can be any non-Hmac PBE 1228# algorithm defined in the Cipher section of the Java Security Standard 1229# Algorithm Names Specification. When set to "NONE", the certificate 1230# is not encrypted. The default value is "PBEWithHmacSHA256AndAES_256". 1231#keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256 1232 1233# The iteration count used by the PBE algorithm when encrypting a certificate. 1234# This value must be a positive integer. The default value is 10000. 1235#keystore.pkcs12.certPbeIterationCount = 10000 1236 1237# The algorithm used to encrypt a private key or secret key. This can be 1238# any non-Hmac PBE algorithm defined in the Cipher section of the Java 1239# Security Standard Algorithm Names Specification. The value must not be "NONE". 1240# The default value is "PBEWithHmacSHA256AndAES_256". 1241#keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256 1242 1243# The iteration count used by the PBE algorithm when encrypting a private key 1244# or a secret key. This value must be a positive integer. The default value 1245# is 10000. 1246#keystore.pkcs12.keyPbeIterationCount = 10000 1247 1248# The algorithm used to calculate the optional MacData at the end of a PKCS12 1249# file. This can be any HmacPBE algorithm defined in the Mac section of the 1250# Java Security Standard Algorithm Names Specification. When set to "NONE", 1251# no Mac is generated. The default value is "HmacPBESHA256". 1252#keystore.pkcs12.macAlgorithm = HmacPBESHA256 1253 1254# The iteration count used by the MacData algorithm. This value must be a 1255# positive integer. The default value is 10000. 1256#keystore.pkcs12.macIterationCount = 10000 1257 1258# 1259# Enhanced exception message information 1260# 1261# By default, exception messages should not include potentially sensitive 1262# information such as file names, host names, or port numbers. This property 1263# accepts one or more comma separated values, each of which represents a 1264# category of enhanced exception message information to enable. Values are 1265# case-insensitive. Leading and trailing whitespaces, surrounding each value, 1266# are ignored. Unknown values are ignored. 1267# 1268# NOTE: Use caution before setting this property. Setting this property 1269# exposes sensitive information in Exceptions, which could, for example, 1270# propagate to untrusted code or be emitted in stack traces that are 1271# inadvertently disclosed and made accessible over a public network. 1272# 1273# The categories are: 1274# 1275# hostInfo - IOExceptions thrown by java.net.Socket and the socket types in the 1276# java.nio.channels package will contain enhanced exception 1277# message information 1278# 1279# jar - enables more detailed information in the IOExceptions thrown 1280# by classes in the java.util.jar package 1281# 1282# The property setting in this file can be overridden by a system property of 1283# the same name, with the same syntax and possible values. 1284# 1285#jdk.includeInExceptions=hostInfo,jar 1286 1287# 1288# Disabled mechanisms for the Simple Authentication and Security Layer (SASL) 1289# 1290# Disabled mechanisms will not be negotiated by both SASL clients and servers. 1291# These mechanisms will be ignored if they are specified in the "mechanisms" 1292# argument of "Sasl.createSaslClient" or the "mechanism" argument of 1293# "Sasl.createSaslServer". 1294# 1295# The value of this property is a comma-separated list of SASL mechanisms. 1296# The mechanisms are case-sensitive. Whitespaces around the commas are ignored. 1297# 1298# Note: This property is currently used by the JDK Reference implementation. 1299# It is not guaranteed to be examined and used by other implementations. 1300# 1301# Example: 1302# jdk.sasl.disabledMechanisms=PLAIN, CRAM-MD5, DIGEST-MD5 1303jdk.sasl.disabledMechanisms= 1304 1305# 1306# Policies for distrusting Certificate Authorities (CAs). 1307# 1308# This is a comma separated value of one or more case-sensitive strings, each 1309# of which represents a policy for determining if a CA should be distrusted. 1310# The supported values are: 1311# 1312# SYMANTEC_TLS : Distrust TLS Server certificates anchored by a Symantec 1313# root CA and issued after April 16, 2019 unless issued by one of the 1314# following subordinate CAs which have a later distrust date: 1315# 1. Apple IST CA 2 - G1, SHA-256 fingerprint: 1316# AC2B922ECFD5E01711772FEA8ED372DE9D1E2245FCE3F57A9CDBEC77296A424B 1317# Distrust after December 31, 2019. 1318# 2. Apple IST CA 8 - G1, SHA-256 fingerprint: 1319# A4FE7C7F15155F3F0AEF7AAA83CF6E06DEB97CA3F909DF920AC1490882D488ED 1320# Distrust after December 31, 2019. 1321# 1322# Leading and trailing whitespace surrounding each value are ignored. 1323# Unknown values are ignored. If the property is commented out or set to the 1324# empty String, no policies are enforced. 1325# 1326# Note: This property is currently used by the JDK Reference implementation. 1327# It is not guaranteed to be supported by other SE implementations. Also, this 1328# property does not override other security properties which can restrict 1329# certificates such as jdk.tls.disabledAlgorithms or 1330# jdk.certpath.disabledAlgorithms; those restrictions are still enforced even 1331# if this property is not enabled. 1332# 1333jdk.security.caDistrustPolicies=SYMANTEC_TLS 1334 1335# 1336# FilePermission path canonicalization 1337# 1338# This security property dictates how the path argument is processed and stored 1339# while constructing a FilePermission object. If the value is set to true, the 1340# path argument is canonicalized and FilePermission methods (such as implies, 1341# equals, and hashCode) are implemented based on this canonicalized result. 1342# Otherwise, the path argument is not canonicalized and FilePermission methods are 1343# implemented based on the original input. See the implementation note of the 1344# FilePermission class for more details. 1345# 1346# If a system property of the same name is also specified, it supersedes the 1347# security property value defined here. 1348# 1349# The default value for this property is false. 1350# 1351jdk.io.permissionsUseCanonicalPath=false 1352 1353 1354# 1355# Policies for the proxy_impersonator Kerberos ccache configuration entry 1356# 1357# The proxy_impersonator ccache configuration entry indicates that the ccache 1358# is a synthetic delegated credential for use with S4U2Proxy by an intermediate 1359# server. The ccache file should also contain the TGT of this server and 1360# an evidence ticket from the default principal of the ccache to this server. 1361# 1362# This security property determines how Java uses this configuration entry. 1363# There are 3 possible values: 1364# 1365# no-impersonate - Ignore this configuration entry, and always act as 1366# the owner of the TGT (if it exists). 1367# 1368# try-impersonate - Try impersonation when this configuration entry exists. 1369# If no matching TGT or evidence ticket is found, 1370# fallback to no-impersonate. 1371# 1372# always-impersonate - Always impersonate when this configuration entry exists. 1373# If no matching TGT or evidence ticket is found, 1374# no initial credential is read from the ccache. 1375# 1376# The default value is "always-impersonate". 1377# 1378# If a system property of the same name is also specified, it supersedes the 1379# security property value defined here. 1380# 1381#jdk.security.krb5.default.initiate.credential=always-impersonate 1382 1383# 1384# Trust Anchor Certificates - CA Basic Constraint check 1385# 1386# X.509 v3 certificates used as Trust Anchors (to validate signed code or TLS 1387# connections) must have the cA Basic Constraint field set to 'true'. Also, if 1388# they include a Key Usage extension, the keyCertSign bit must be set. These 1389# checks, enabled by default, can be disabled for backward-compatibility 1390# purposes with the jdk.security.allowNonCaAnchor System and Security 1391# properties. In the case that both properties are simultaneously set, the 1392# System value prevails. The default value of the property is "false". 1393# 1394#jdk.security.allowNonCaAnchor=true 1395 1396# 1397# The default Character set name (java.nio.charset.Charset.forName()) 1398# for converting TLS ALPN values between byte arrays and Strings. 1399# Prior versions of the JDK may use UTF-8 as the default charset. If 1400# you experience interoperability issues, setting this property to UTF-8 1401# may help. 1402# 1403# jdk.tls.alpnCharset=UTF-8 1404jdk.tls.alpnCharset=ISO_8859_1 1405 1406# 1407# Global JNDI Object Factories Filter 1408# 1409# This filter is used by the JNDI runtime to control the set of object factory classes 1410# which will be allowed to instantiate objects from object references returned by 1411# naming/directory systems. The factory class named by the reference instance will be 1412# matched against this filter. The filter property supports pattern-based filter syntax 1413# with the same format as jdk.serialFilter. Limit patterns specified in the filter property 1414# are unused. 1415# 1416# Each class name pattern is matched against the factory class name to allow or disallow its 1417# instantiation. The access to a factory class is allowed if the filter returns 1418# ALLOWED. 1419# 1420# Note: This property is currently used by the JDK Reference implementation. 1421# It is not guaranteed to be examined and used by other implementations. 1422# 1423# If the system property jdk.jndi.object.factoriesFilter is also specified, it supersedes 1424# the security property value defined here. The default value of the property is "*". 1425# 1426# The default pattern value allows any object factory class specified by the reference 1427# instance to recreate the referenced object. 1428#jdk.jndi.object.factoriesFilter=* 1429 1430# 1431# Protocol Specific JNDI/LDAP Object Factories Filter 1432# 1433# This filter is used by the JNDI/LDAP provider implementation in the JDK to further control the 1434# set of object factory classes which will be allowed to instantiate objects from object 1435# references bound to LDAP contexts. The factory class named by the reference instance will 1436# be matched against this filter. The filter property supports pattern-based filter syntax 1437# with the same format as jdk.serialFilter. Limit patterns specified in the filter property 1438# are unused. 1439# 1440# Each class name pattern is matched against the factory class name to allow or disallow its 1441# instantiation. The access to a factory class is allowed only when it is not rejected by this filter 1442# or by the global filter defined by "jdk.jndi.object.factoriesFilter", and at least one of these 1443# two filters returns ALLOWED. 1444# 1445# Note: This property is currently used by the JDK Reference implementation. 1446# It is not guaranteed to be examined and used by other implementations. 1447# 1448# If the system property jdk.jndi.ldap.object.factoriesFilter is also specified, it supersedes 1449# the security property value defined here. The default value of the property is 1450# "java.naming/com.sun.jndi.ldap.**;!*". 1451# 1452# The default pattern value allows any object factory class defined in the java.naming module 1453# to be specified by the reference instance, but rejects any other. 1454#jdk.jndi.ldap.object.factoriesFilter=java.naming/com.sun.jndi.ldap.**;!* 1455 1456# 1457# Protocol Specific JNDI/RMI Object Factories Filter 1458# 1459# This filter is used by the JNDI/RMI provider implementation in the JDK to further control the 1460# set of object factory classes which will be allowed to instantiate objects from object 1461# references bound to RMI names. The factory class named by the reference instance will 1462# be matched against this filter. The filter property supports pattern-based filter syntax 1463# with the same format as jdk.serialFilter. Limit patterns specified in the filter property 1464# are unused. 1465# 1466# Each class name pattern is matched against the factory class name to allow or disallow its 1467# instantiation. The access to a factory class is allowed only when it is not rejected by this filter 1468# or by the global filter defined by "jdk.jndi.object.factoriesFilter", and at least one of these 1469# two filters returns ALLOWED. 1470# 1471# Note: This property is currently used by the JDK Reference implementation. 1472# It is not guaranteed to be examined and used by other implementations. 1473# 1474# If the system property jdk.jndi.rmi.object.factoriesFilter is also specified, it supersedes 1475# the security property value defined here. The default value of the property is 1476# "jdk.naming.rmi/com.sun.jndi.rmi.**;!*". 1477# 1478# The default pattern value allows any object factory class defined in the jdk.naming.rmi module 1479# to be specified by the reference instance, but rejects any other. 1480#jdk.jndi.rmi.object.factoriesFilter=jdk.naming.rmi/com.sun.jndi.rmi.**;!* 1481 1482# 1483# Policy for non-forwardable service ticket in a S4U2proxy request 1484# 1485# The Service for User to Proxy (S4U2proxy) Kerberos extension enables a middle service 1486# to obtain a service ticket to another service on behalf of a user. It requires that 1487# the user's service ticket to the first service has the forwardable flag set [1]. 1488# However, some KDC implementations ignore this requirement and accept service tickets 1489# with the flag unset. 1490# 1491# If this security property is set to "true", then 1492# 1493# 1) The user service ticket, when obtained by the middle service after a S4U2self 1494# impersonation, is not required to have the forwardable flag set; and, 1495# 1496# 2) If a S4U2proxy request receives a KRB_ERROR of the KDC_ERR_BADOPTION error code 1497# and the ticket to the middle service is not forwardable, OpenJDK will try the same 1498# request with another KDC instead of treating it as a fatal failure. 1499# 1500# The default value is "false". 1501# 1502# If a system property of the same name is also specified, it supersedes the 1503# security property value defined here. 1504# 1505# [1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/bde93b0e-f3c9-4ddf-9f44-e1453be7af5a 1506#jdk.security.krb5.s4u2proxy.acceptNonForwardableServiceTicket=false 1507