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