Heim >Java >javaLernprogramm >Nach Java8 (291) ist TLS1.1 deaktiviert und JDBC kann keine Verbindung zu SqlServer2008 über SSL herstellen. Wie kann das Problem gelöst werden?

Nach Java8 (291) ist TLS1.1 deaktiviert und JDBC kann keine Verbindung zu SqlServer2008 über SSL herstellen. Wie kann das Problem gelöst werden?

WBOYnach vorne: 2023-05-16 23:55:052035Durchsuche

Nach Java8-291 ist TLS1.1 deaktiviert, sodass JDBC keine Verbindung zu SqlServer2008 über SSL herstellen kann. Was soll ich tun?

Die Datei java.security ändern# 🎜🎜#

1. Suchen Sie die java.security-Datei von jre

Wenn es sich um jre handelt, in {JAVA_HOME}/jre/lib/security, z. B.????#🎜🎜 #

C:ProgrammeJavajre1.8.0_301libsecurity

Wenn es sich um eine Eclipse Green-installationsfreie tragbare Version handelt

Suchen Sie in der Installation nach java.security Ordner, wie etwa????

# 🎜🎜#
xxxpluginsorg.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_16.0.1.v20210528-1205jreconfsecurity

#🎜🎜 #

Wenn es sich um die installierte Version von Eclipse unter Fenster
handelt, befindet sich die Datei beispielsweise in c:/Benutzerordner/.p2/pool/plugins/…????
# 🎜🎜#

C:Usersadmin.p2poolpluginsorg.eclipse.justj .openjdk.hotspot.jre.full.win32.x86_64_16.0.2.v20210721-1149jreconfsecurity

If Du suchst nach java.security auf dem Laufwerk C, möglicherweise finden Sie mehr als zwei im temporären Ordner 🎜#

jdk.tls.disabledAlgorithms=

#🎜🎜 #

kann gefunden werden??? #

# Example:
#   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, \
#       rsa_pkcs1_sha1, secp224r1
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL

4. Speichern, das war's

Das geänderte Beispiel kann direkt in jre8 kopiert werden.

#

# Eine alternative java.security-Eigenschaftendatei kann

# von der Befehlszeile über die Systemeigenschaft
#
# -Djava.security.properties= angegeben werden 258c40d94d8689854ad79c4076dd5f96

# Diese Eigenschaftendatei wird an die Master-Sicherheitseigenschaftendatei angehängt.

# Wenn beide Eigenschaftendateien Werte für denselben Schlüssel angeben, wird der Wert

# aus der Befehlszeilen-Eigenschaftendatei wird ausgewählt, da es sich um die zuletzt geladene handelt.

# Auch wenn Sie

# -Djava angeben .security.properties==258c40d94d8689854ad79c4076dd5f96 (2 gleich),

# dann überschreibt diese Eigenschaftendatei vollständig die Master-Sicherheit

# Eigenschaftendatei.

##🎜🎜 ## Um die Möglichkeit zu deaktivieren, eine zusätzliche Eigenschaftendatei über die Befehlszeile anzugeben, setzen Sie den Schlüssel security.overridePropertiesFile

# in der Hauptsicherheitseigenschaftendatei auf „true“. ## standardmäßig.

# In dieser Datei werden verschiedene Sicherheitseigenschaften für die Verwendung durch
# Java-Sicherheitsklassen festgelegt. Hier können Benutzer das
# Kryptographiepaket statisch registrieren Anbieter (kurz „Anbieter“). Der Begriff „Anbieter“ bezieht sich auf ein Paket oder eine Reihe von Paketen, die eine konkrete Implementierung einer Teilmenge der kryptografischen Aspekte bereitstellen Java Security API. Ein Anbieter kann beispielsweise einen oder mehrere digitale Signaturalgorithmen oder Message Digest-Algorithmen implementieren.
#
# Jeder Anbieter muss eine Unterklasse der Provider-Klasse implementieren.# 🎜🎜## Um einen Anbieter in dieser Master-Sicherheitseigenschaftendatei zu registrieren,
# geben Sie den Anbieter und die Priorität im Format
#
# security.provider.751fecf49c9d13ca89ee2cbb9b75d4f6=d118035abdcf7cbe780ed943e8bb5503
#
# Dies deklariert einen Anbieter und gibt seine Präferenz an.
# Reihenfolge n Die Präferenzreihenfolge ist die Reihenfolge, in der Anbieter nach angeforderten Algorithmen durchsucht werden ( wenn kein bestimmter Anbieter
# angefordert wird). ;provName> muss den Namen des Anbieters angeben, der an den Konstruktor der Super
#-Klasse java.security.Provider übergeben wird. Dies gilt für Anbieter, die
# über den ServiceLoader-Mechanismus geladen werden.
##🎜 🎜## ba8676586cb33c74c61ba2c0b1d97e34 muss die Unterklasse der Provider-Klasse angeben, deren
# Konstruktor die Werte verschiedener Eigenschaften festlegt, die erforderlich sind#🎜 🎜##, damit die Java Security API die Algorithmen oder andere nachschlagen kann
# Vom Anbieter implementierte Funktionen. Dies gilt für Anbieter, die über den Klassenpfad geladen werden.
#
# entweder die Methode addProvider oder insertProviderAt in der Klasse Security
#.

#
# Liste der Anbieter und ihrer Präferenzreihenfolgen (siehe oben):
##🎜🎜 #security.provider.1=SUN
security.provider.2=SunRsaSign
security.provider.3=SunEC
security .provider.4=SunJSSE
security.provider.5 =SunJCE
security.provider.6=SunJGSS
security.provider.7=SunSASL
security.provider.8=XMLDSig
security.provider.9=SunPCSC
security.provider.10=JdkLDAP
security.provider.11=JdkSASL
security.provider.12=SunMSCAPI
security.provider.13=SunPKCS11

#
# Eine Liste bevorzugter Anbieter für bestimmte Algorithmen. Diese Anbieter werden
# vor der Liste der registrierten Anbieter nach passenden Algorithmen durchsucht.
# Einträge mit Fehlern (Parsing usw.) werden ignoriert. Verwenden Sie die Eigenschaft
# -Djava.security.debug=jca, um diese Fehler zu debuggen.
#
# Die Eigenschaft ist eine durch Kommas getrennte Liste von serviceType.algorithm:provider
#-Einträgen. Der ServiceType (Beispiel: „MessageDigest“) ist optional, und wenn
# nicht angegeben, gilt der Algorithmus für alle Servicetypen, die ihn unterstützen.
# Der Algorithmus ist der Standardalgorithmusname oder die Standardtransformation.
# Transformationen können in ihrem angegeben werden vollständiger Standardname
# (z. B. AES/CBC/PKCS5Padding) oder als Teilübereinstimmungen (z. B. AES, AES/CBC).
# Der Anbieter ist der Name des Anbieters. Jeder Anbieter, der nicht
# auch in der registrierten Liste erscheint, wird ignoriert.
#
# Es gibt einen speziellen ServiceType für diese Eigenschaft, nur um eine Reihe von
# Algorithmen zu gruppieren. Der Typ ist „Gruppe“ und wird von einem algorithmischen #-Schlüsselwort gefolgt. Gruppen sollen die Einträge in der Zeile property
# vereinfachen und reduzieren. Aktuelle Gruppen sind:
# Group.SHA2 = SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256
# Group.HmacSHA2 = HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512
# Group.SHA2RSA = SHA224withRSA, SHA256withRSA, SHA384withRSA, SHA512withRSA
# Group.SHA2DSA = SHA224withDSA, SHA256withDSA, SHA384withDSA, SHA512withDSA
# Group.SHA2ECDSA = SHA224withECDSA, SHA256with ECDSA, SHA384withECDSA,
# SHA512withECDSA
# Group.SHA3 = SHA3-224 , SHA3-256, SHA3-384, SHA3-512
# Group.HmacSHA3 = HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512
#
# Beispiel:
# jdk.security.provider.preferred=AES /GCM/NoPadding:SunJCE,
# MessageDigest.SHA-256:SUN, Group.HmacSHA2:SunJCE
#
#jdk.security.provider.preferred=

#
# Sun Provider SecureRandom Seed-Quelle.
#
# Wählen Sie die primäre Quelle der Seed-Daten für die SecureRandom-Implementierungen „NativePRNG“, „SHA1PRNG“
# und „DRBG“ im „Sun“-Anbieter aus.
# (Andere SecureRandom-Implementierungen könnten diese Eigenschaft ebenfalls verwenden.)
#
# Unter Unix -ähnliche Systeme (z. B. Linux/MacOS) beziehen die Implementierungen
# „NativePRNG“, „SHA1PRNG“ und „DRBG“ Startdaten aus
# speziellen Gerätedateien wie file:/dev/random.
#
# Ein Windows-Systeme aktivieren durch Angabe der URLs „file:/dev/random“ oder
# „file:/dev/urandom“ den nativen Microsoft CryptoAPI-Seeding-Mechanismus
# für SHA1PRNG und DRBG.
#
# Standardmäßig ist ein Versuch gemacht, um das Entropie-Sammelgerät zu verwenden
#, das durch die Sicherheitseigenschaft „securerandom.source“ angegeben wird. Wenn beim Zugriff auf die angegebene URL:
#
# NativePRNG:
# eine
# Ausnahme auftritt, wird ein Standardwert von /dev/random verwendet. Wenn weder
# verfügbar sind, wird die Implementierung deaktiviert.
# „Datei“ ist der einzige derzeit unterstützte Protokolltyp.
#
# SHA1PRNG und DRBG:
# der herkömmliche System-/Thread-Aktivitätsalgorithmus wird verwendet.
#
# Das Entropiesammelgerät kann auch mit der System
#-Eigenschaft „java.security.egd“ angegeben werden. Zum Beispiel:
#
# % java -Djava.security.egd=file:/dev/random MainClass
#
# Die Angabe dieser Systemeigenschaft überschreibt die
# „securerandom.source“-Sicherheitseigenschaft.
#
# Darüber hinaus , wenn „file:/dev/random“ oder „file:/dev/urandom“ angegeben ist
#, wird die „NativePRNG“-Implementierung bevorzugter als
# DRBG und SHA1PRNG im Sun-Anbieter.
#
securerandom.source =file:/dev/random
#
# Eine Liste bekannter starker SecureRandom-Implementierungen.
#
# Um Anwendungen bei der Auswahl einer geeigneten starken
# java.security.SecureRandom-Implementierung zu unterstützen, sollten Java-Distributionen
# eine Liste angeben bekannter starker Implementierungen, die die Eigenschaft verwenden.
#
# Dies ist eine durch Kommas getrennte Liste von Algorithmus- und/oder algorithm:provider
#-Einträgen.
#
securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI,DRBG:SUN

#
# DRBG-Konfiguration und Standardinstanziierungsanforderung des Sun-Anbieters.
#
# NIST SP 800-90Ar1 listet mehrere DRBG-Mechanismen auf. Jedes kann mit einem DRBG-Algorithmusnamen konfiguriert
# und mit einer Sicherheitsstärke,
# Vorhersageresistenzunterstützung usw. instanziiert werden. Diese Eigenschaft definiert die Konfiguration
# und die Standardinstanziierungsanforderung von „DRBG“ SecureRandom-Implementierungen
# in der SUN-Anbieter. (Andere DRBG-Implementierungen können diese Eigenschaft ebenfalls verwenden.)
# Anwendungen können verschiedene Instanziierungsparameter wie Sicherheit
# Stärke, Fähigkeit, Personalisierungszeichenfolge mithilfe einer der
# getInstance(...,SecureRandomParameters,...)-Methoden mit a anfordern
# DrbgParameters.Instantiation-Argument, aber andere Einstellungen wie der
#-Mechanismus und die DRBG-Algorithmusnamen können derzeit von keiner API konfiguriert werden.
#
# Bitte beachten Sie, dass die SUN-Implementierung von DRBG immer ein erneutes Seeding unterstützt.
#
# Der Wert dieser Eigenschaft ist eine durch Kommas getrennte Liste aller konfigurierbaren
# Aspekte. Die Aspekte können in beliebiger Reihenfolge erscheinen, aber derselbe Aspekt kann höchstens
# einmal vorkommen. Seine Definition im BNF-Stil lautet:
#
# Wert:
# Aspekt { "," Aspekt }
#
# Aspekt:
# mech_name | algorithm_name | Stärke | Fähigkeit | df
#
# // Der zu verwendende DRBG-Mechanismus. Standard „Hash_DRBG“
# mech_name:
# „Hash_DRBG“ | „HMAC_DRBG“ | "CTR_DRBG"
#
# // Der Name des DRBG-Algorithmus. Die „SHA-***“-Namen gelten für Hash_DRBG und
# // HMAC_DRBG, Standardwert „SHA-256“. Die „AES-***“-Namen gelten für CTR_DRBG,
# // Standard „AES-128“ bei Verwendung der eingeschränkten Kryptografie oder „AES-256“
# // bei Verwendung der unbegrenzten Verschlüsselung.
# algorithm_name:
# " SHA-224" | „SHA-512/224“ | „SHA-256“ |
# „SHA-512/256“ | „SHA-384“ | „SHA-512“ |
# „AES-128“ | „AES-192“ | „AES-256“
#
# // Sicherheitsstärke angefordert. Standard „128“
# Stärke:
# „112“ | „128“ | „192“ | "256"
#
# // Vorhersagewiderstand und Neuaussaatanfrage. Standardmäßig „none“
# // „pr_and_reseed“ – Sowohl Vorhersagewiderstand als auch Reseed-Unterstützung angefordert
# // „reseed_only“ – Nur Reseed-Unterstützung angefordert
# // „none“ - Weder Vorhersageresistenz nicht. resee ding
# // Unterstützung angefordert
# pr:
# "pr_and_reseed" | „reseed_only“ | "none"
#
# // Ob eine Ableitungsfunktion verwendet werden soll. gilt nur
# // für CTR_DRBG. Standard „use_df“
# df:
# „use_df“ | "no_df"
#
# Beispiele,
# securerandom.drbg.config=Hash_DRBG,SHA-224,112,none
# securerandom.drbg.config=CTR_DRBG,AES-256,192,pr_and_reseed,use_df
#
# Der Standardwert ist ein leere Zeichenfolge, die äquivalent ist
# securerandom.drbg.config=Hash_DRBG,SHA-256,128,none
#
securerandom.drbg.config=
#
# Klasse zur Instanziierung als javax.security.auth.login.Configuration
# Provider.
#
login.configuration.provider=sun.security.provider.ConfigFile
#
# Standard-Login-Konfigurationsdatei
#
#login.config.url.1=file:${user.home}/ .java.login.config
#
# Klasse, die als Systemrichtlinie instanziiert werden soll. Dies ist der Name der Klasse
#, die als Richtlinienobjekt verwendet wird. Der Systemklassenlader wird verwendet, um diese Klasse zu lokalisieren Das Home-Verzeichnis des Benutzers.
#
policy.url.1=file:${java.home}/conf/security/java.policy
policy.url.2=file:${user.home}/.java.policy
# Steuert, ob Eigenschaften in Richtlinien- und Anmeldekonfigurationsdateien erweitert werden oder nicht. Wenn auf „false“ gesetzt, werden Eigenschaften (${...}) nicht
# in Richtlinien- und Anmeldekonfigurationsdateien erweitert. Wenn er auskommentiert oder
# auf eine leere Zeichenfolge gesetzt ist, ist der Standardwert „false“ für Richtliniendateien und
# „true“ für Anmeldekonfigurationsdateien.
#
policy.expandProperties=true

# Steuert, ob eine zusätzliche Richtlinien- oder Anmeldekonfigurationsdatei
# auf der Befehlszeile mit -Djava.security.policy=somefile
# oder -Djava.security übergeben werden darf. auth.login.config=irgendeineDatei. Wenn er auskommentiert oder auf eine leere Zeichenfolge gesetzt ist, ist der Standardwert „false“.
#
policy.allowSystemProperty=true
# ob wir Suchen Sie im IdentityScope nach vertrauenswürdigen Identitäten
#, wenn Sie auf eine 1.1 signierte JAR-Datei stoßen. Wenn die Identität gefunden wird
# und vertrauenswürdig ist, gewähren wir ihr AllPermission. Hinweis: Der Standardrichtlinienanbieter (sun.security.provider.PolicyFile) unterstützt diese Eigenschaft nicht.
#
policy.ignoreIdentityScope=false

## 🎜🎜## Standard-Keystore-Typ.
#
keystore.type=pkcs12

#
# Steuert den Kompatibilitätsmodus für JKS- und PKCS12-Keystore-Typen.
#
# Wenn auf „true“ gesetzt, unterstützen sowohl JKS- als auch PKCS12-Keystore-Typen das Laden
# Keystore-Dateien im JKS- oder PKCS12-Format. Wenn auf „false“ gesetzt, unterstützt der
# JKS-Keystore-Typ nur das Laden von JKS-Keystore-Dateien und der PKCS12
# Keystore-Typ unterstützt nur das Laden von PKCS12-Keystore-Dateien.
#
keystore.type .compat=true

#
# Liste der durch Kommas getrennten Pakete, die mit dieser Zeichenfolge beginnen oder dieser entsprechen
# führt dazu, dass eine Sicherheitsausnahme ausgelöst wird, wenn sie an #🎜 übergeben wird 🎜## SecurityManager::checkPackageAccess-Methode, es sei denn, die entsprechende
# RuntimePermission("accessClassInPackage."+package) wurde gewährt.
#
package.access=sun.misc.,#🎜🎜 # sun.reflect.

#
# Liste der durch Kommas getrennten Pakete, die mit dieser Zeichenfolge beginnen oder dieser entsprechen
# löst bei Übergabe an # eine Sicherheitsausnahme aus 🎜🎜## SecurityManager::checkPackageDefinition-Methode, es sei denn, die entsprechende
# RuntimePermission("defineClassInPackage."+package) wurde gewährt.
#
# Standardmäßig wird keiner der Klassenlader mitgeliefert Der JDK -Anruf#🎜🎜 ## checkpackagedefinition.#🎜🎜 ### 🎜🎜##package.definition = sun.misc.,
sun.reflect.#🎜🎜 ## 🎜🎜 ### 🎜🎜 ## Bestimmt, ob diese Eigenschaftendatei an
# angehängt oder in der Befehlszeile über -Djava.security.properties
#
security.overridePropertiesFile=true

# überschrieben werden kann
# Bestimmt die Standard-Schlüssel- und Trust-Manager-Factory-Algorithmen für
# das javax.net.ssl-Paket.
#
ssl.KeyManagerFactory.algorithm=SunX509
ssl. TrustManagerFactory.algorithm=PKIX

#
# Die Namelookup-Cache-Richtlinie auf Java-Ebene für erfolgreiche Suchvorgänge:
#
# jeder negative Wert: für immer zwischenspeichern
# irgendein positiver Wert: die Anzahl der Sekunden, die eine Adresse zwischengespeichert werden soll
# Null: nicht zwischenspeichern
#
# Der Standardwert ist für immer (FÜR IMMER). Aus Sicherheitsgründen wird dieses
# Caching dauerhaft durchgeführt, wenn ein Sicherheitsmanager festgelegt wird. Wenn kein Sicherheitsmanager festgelegt ist, besteht das Standardverhalten in dieser Implementierung darin, 30 Sekunden lang zwischenzuspeichern Der Standardwert kann
# schwerwiegende Auswirkungen auf die Sicherheit haben. Legen Sie es nicht fest, es sei denn
# Sie sind sicher, dass Sie keinem DNS-Spoofing-Angriff ausgesetzt sind Namelookup-Cache-Richtlinie auf Java-Ebene für fehlgeschlagene Lookups:
#
# beliebiger negativer Wert: für immer zwischenspeichern
# beliebiger positiver Wert: die Anzahl der Sekunden, die negative Lookup-Ergebnisse zwischengespeichert werden
# Null : nicht zwischenspeichern
#
# In einigen Microsoft Windows-Netzwerkumgebungen, die zusätzlich zum DNS den WINS-Namensdienst verwenden, können fehlgeschlagene Namensdienst-Suchen
# eine beträchtliche Zeit in Anspruch nehmen lange Zeit bis zur Rückkehr (ca. 5 Sekunden).
# Aus diesem Grund besteht die Standard-Caching-Richtlinie darin, diese
# Ergebnisse 10 Sekunden lang beizubehalten.
#
networkaddress.cache. negative.ttl=10

#
# Eigenschaften zum Konfigurieren von OCSP für die Zertifikatssperrprüfung
#

# OCSP aktivieren
##🎜 🎜## Standardmäßig wird OCSP nicht für die Zertifikatssperrprüfung verwendet.
# Diese Eigenschaft ermöglicht die Verwendung von OCSP, wenn sie auf den Wert „true“ gesetzt ist.
#
# HINWEIS: SocketPermission ist erforderlich, um eine Verbindung zu einem OCSP-Responder herzustellen.
#
# Beispiel,
# ocsp.enable=true

#
# Standort des OCSP-Responders# 🎜🎜##
# Standardmäßig wird der Standort des OCSP-Responders implizit
# aus dem zu validierenden Zertifikat ermittelt. Diese Eigenschaft gibt explizit
# den Standort des OCSP-Responders an. Die Eigenschaft wird verwendet, wenn die
# Authority Information Access-Erweiterung (definiert in RFC 5280) im Zertifikat fehlt
# oder wenn sie überschrieben werden muss.
#
# Beispiel,# 🎜🎜## ocsp.responderURL=http://ocsp.example.net:80

#
# Betreffname des Zertifikats des OCSP-Responders
#
# Standardmäßig ist das Zertifikat des OCSP-Responders das des Ausstellers
# des zu validierenden Zertifikats. Diese Eigenschaft identifiziert die Zertifikatsnummer des OCSP-Responders, wenn die Standardeinstellung nicht zutrifft. Sein Wert ist eine Zeichenfolge
# Distinguished Name (definiert in RFC 2253), die ein Zertifikat in
# dem Satz von Zertifikaten identifiziert, die während der Zertifikatpfadvalidierung bereitgestellt werden. In Fällen, in denen
# der Betreffname allein nicht ausreicht, um das Zertifikat eindeutig zu identifizieren
#, müssen stattdessen sowohl die Eigenschaften „ocsp.responderCertIssuerName“ als auch
# „ocsp.responderCertSerialNumber“ verwendet werden. Wenn diese
#-Eigenschaft festgelegt ist, werden diese beiden Eigenschaften ignoriert.
#
# Beispiel:
# ocsp.responderCertSubjectName=CN=OCSP-Responder, O=XYZ Corp
#
# Ausstellername des Zertifikats des OCSP-Responders
#
# Standardmäßig ist das Zertifikat des OCSP-Responders das des Ausstellers
# des zu validierenden Zertifikats. Diese Eigenschaft identifiziert die Zertifikatsnummer des OCSP-Responders, wenn die Standardeinstellung nicht zutrifft. Sein Wert ist eine Zeichenfolge
# Distinguished Name (definiert in RFC 2253), die ein Zertifikat in
# dem Satz von Zertifikaten identifiziert, die während der Zertifikatpfadvalidierung bereitgestellt werden. Wenn diese Eigenschaft festgelegt ist, muss auch die Eigenschaft „ocsp.responderCertSerialNumber“ festgelegt werden. Wenn die Eigenschaft „ocsp.responderCertSubjectName“ festgelegt ist, wird diese Eigenschaft ignoriert Zertifikat
#
# Standardmäßig ist das Zertifikat des OCSP-Responders das des Ausstellers
# des zu validierenden Zertifikats. Diese Eigenschaft identifiziert die Zertifikatsnummer des OCSP-Responders, wenn die Standardeinstellung nicht zutrifft. Sein Wert ist eine Zeichenfolge
# aus hexadezimalen Ziffern (Doppelpunkt oder Leerzeichen können vorhanden sein), die
# ein Zertifikat im Satz von Zertifikaten identifiziert, die während der Zertifikatspfadvalidierung bereitgestellt werden
#. Wenn diese Eigenschaft festgelegt ist, muss auch die Eigenschaft „ocsp.responderCertIssuerName“
# festgelegt werden. Wenn die Eigenschaft „ocsp.responderCertSubjectName“ festgelegt ist, wird diese Eigenschaft ignoriert # Wenn ein KDC nicht verfügbar ist (Netzwerkfehler, Dienstausfall usw.), wird es
# in eine Blacklist aufgenommen und für zukünftige Anfragen seltener aufgerufen. Der
#-Wert (ohne Berücksichtigung der Groß- und Kleinschreibung) für diese Richtlinie kann sein:
#
# tryLast
# KDCs in der Blacklist werden immer nach denen ausprobiert, die nicht auf der Liste stehen.
#
# tryLess[:max_retries,timeout]
# KDCs in der Blacklist werden immer noch in ihrer Reihenfolge in der Konfiguration ausprobiert,
# aber mit kleineren max_retries- und Timeout-Werten. max_retries und timeout
# sind optionale numerische Parameter (Standard 1 und 5000, was einmal
# und 5 Sekunden bedeutet). Bitte beachten Sie, dass, wenn einer der hier definierten Werte
# größer als der in krb5.conf definierte Wert ist, er ignoriert wird.
#
# Immer wenn ein KDC als verfügbar erkannt wird, wird es aus der Blacklist entfernt.
# Der Die Blacklist wird zurückgesetzt, wenn krb5.conf neu geladen wird. Sie können
# restartKrb5Config=true zu einer JAAS-Konfigurationsdatei hinzufügen, sodass krb5.conf
# jedes Mal neu geladen wird, wenn eine JAAS-Authentifizierung versucht wird.
#
# Beispiel:
# krb5.kdc.bad.policy = tryLast
# krb5. kdc.bad.policy = tryLess:2,2000
#
krb5.kdc.bad.policy = tryLast

#
# Kerberos Cross-Realm-Verweise (RFC 6806)
#
# Der Kerberos-Client von OpenJDK unterstützt Cross-Realm-Verweise als definiert in
# RFC 6806. Dies ermöglicht die Einrichtung dynamischerer Umgebungen, in denen Clients
# nicht im Voraus wissen müssen, wie sie den Bereich eines Zielprinzipals
# (entweder eines Benutzers oder eines Dienstes) erreichen können.
#
# Wann Wenn ein Client eine AS- oder TGS-Anfrage ausgibt, wird die Option „canonicalize“
# gesetzt, um die Unterstützung dieser Funktion anzukündigen. Ein KDC-Server kann die
#-Anfrage erfüllen oder antworten und den Client an einen anderen verweisen. Bei einer Weiterleitung
# gibt der Client eine neue Anfrage aus und der Zyklus wiederholt sich.
#
# Zusätzlich zu Weiterleitungen ermöglicht die Option „Kanonisieren“ dem KDC-Server
#, den Clientnamen als Reaktion auf eine AS-Anfrage zu ändern. Aus Sicherheitsgründen wird
# RFC 6806 (Abschnitt 11) das FAST-Schema durchgesetzt.
#
# Kerberos-Cross-Realm-Verweise deaktivieren. Der Wert kann mit einer
# Systemeigenschaft (-Dsun.security.krb5.disableReferrals) überschrieben werden.
sun.security.krb5.disableReferrals=false

# Maximale Anzahl von AS- oder TGS-Verweisen, um Endlosschleifen zu vermeiden. Der Wert kann
# mit einer Systemeigenschaft überschrieben werden (-Dsun.security.krb5.maxReferrals).
sun.security.krb5.maxReferrals=5

#
# Diese Eigenschaft enthält eine Liste deaktivierter benannter EC-Kurven, die
# in die jdk.[tls|certpath|jar].disabledAlgorithms-Eigenschaften aufgenommen werden können. Um diese
# Liste in eine der „disabledAlgorithms“-Eigenschaften aufzunehmen, fügen Sie den Eigenschaftsnamen als
# einen Eintrag hinzu.
#jdk.disabled.namedCurves=

#
# Algorithmusbeschränkungen für die Verarbeitung des Zertifizierungspfads (CertPath)
#
# In einigen Umgebungen können bestimmte Algorithmen oder Schlüssellängen unerwünscht sein
# für die Erstellung des Zertifizierungspfads und Validierung. Beispielsweise gilt „MD2“ im Allgemeinen nicht mehr als sicherer Hash-Algorithmus. In diesem Abschnitt
# wird der Mechanismus zum Deaktivieren von Algorithmen basierend auf dem Algorithmusnamen
# und/oder der Schlüssellänge beschrieben. Dazu gehören auch in Zertifikaten verwendete Algorithmen
# Sperrinformationen wie CRLs und signierte OCSP-Antworten.
# Die Syntax der deaktivierten Algorithmuszeichenfolge wird wie folgt beschrieben:
# DisabledAlgorithms:# 🎜🎜## " DisabledAlgorithm { , DisabledAlgorithm } "
#
# DisabledAlgorithm:
# AlgorithmName [Constraint] { '&' Constraint } | IncludeProperty
#
# AlgorithmName:
# (siehe unten)
#
# Constraint:
# KeySizeConstraint | CAConstraint | DenyAfterConstraint |
# UsageConstraint
#
# KeySizeConstraint:
# keySize Operator KeyLength
#
# b1c9ed4f687c0238205d15575a6578ff= | >
#
# KeyLength:
# Ganzzahliger Wert der Schlüssellänge des Algorithmus in Bits
#
# CAConstraint:
# jdkCA
##?? # #
# IncludeProperty:
# include a156e5fabe8bc64803b269b34a370726
#
# Der „AlgorithmName“ ist der Standardalgorithmusname des deaktivierten
# Algorithmus. Weitere Informationen zu Standardalgorithmnamen finden Sie in der Java Security Standard Algorithm Names Specification
#. Der Abgleich erfolgt
# mithilfe einer Unterelement-Abgleichsregel, bei der die Groß-/Kleinschreibung nicht beachtet wird. (Zum Beispiel: In „SHA1withECDSA“ sind die Unterelemente „SHA1“ für Hashing und
# „ECDSA“ für Signaturen.) Wenn die Behauptung „AlgorithmName“ ein
# Unterelement ist Element des Namens des Zertifikatsalgorithmus, wird der Algorithmus
# während der Erstellung und Validierung des Zertifizierungspfads abgelehnt. Beispielsweise deaktiviert
# der Assertionsalgorithmusname „DSA“ alle Zertifikatsalgorithmen
#, die auf DSA basieren, wie z. B. NONEwithDSA, SHA1withDSA. Die Behauptung
# deaktiviert jedoch keine Algorithmen im Zusammenhang mit „ECDSA“.
#
# Die „IncludeProperty“ ermöglicht eine durch die Implementierung definierte Sicherheitseigenschaft, in die
# eingebunden werden kann diedisabledAlgorithms-Eigenschaften. Diese Eigenschaften dienen
# dazu, allgemeine Aktionen einfacher über mehrere invalidAlgorithm
# Eigenschaften hinweg zu verwalten.
# Es gibt eine definierte Sicherheitseigenschaft: jdk.disabled.NamedCurves
# Siehe die Eigenschaft für genauere Details.
#
#
# Eine „Einschränkung“ definiert Einschränkungen für die Schlüssel und/oder Zertifikate für
# einen angegebenen AlgorithmusName:
##🎜🎜 ## KeySizeConstraint:
# keySize Operator KeyLength
# Die Einschränkung erfordert einen Schlüssel eines gültigen Größenbereichs, wenn
# „AlgorithmName“ zu einem Schlüsselalgorithmus gehört. Die „KeyLength“ gibt
# die Schlüsselgröße an, die in der Anzahl der Bits angegeben wird. Beispielsweise gibt
# "RSA keySize d507521b6debf6a34a62b044a5b67bac 2048“ gibt an, dass jeder RSA-Schlüssel
# mit einer Schlüsselgröße kleiner als 1024 oder größer als 2048 deaktiviert werden sollte.
# Diese Einschränkung wird nur bei Algorithmen verwendet, die eine Schlüsselgröße haben .
#
# CAConstraint:
# jdkCA
# Diese Einschränkung verbietet den angegebenen Algorithmus nur, wenn der
# -Algorithmus in einer Zertifikatskette verwendet wird, die an einer markierten Stelle endet
# Vertrauensanker im Schlüsselspeicher lib/security/cacerts. Wenn die jdkCA
# -Einschränkung nicht festgelegt ist, sind alle Ketten, die den angegebenen Algorithmus
# verwenden, eingeschränkt. jdkCA darf nur einmal in einem DisabledAlgorithm-Ausdruck verwendet werden. #
# DenyAfterConstraint:
# denyAfter YYYY-MM-DD
# Diese Einschränkung verhindert, dass ein Zertifikat mit dem angegebenen Algorithmus
# nach dem Datum verwendet wird, unabhängig von der Gültigkeit des Zertifikats
# . JAR-Dateien, die vor dem
# -Beschränkungsdatum mit Zertifikaten signiert und mit einem Zeitstempel versehen wurden, die den deaktivierten Algorithmus enthalten
# , werden nicht eingeschränkt. Das Datum wird in der UTC-Zeitzone verarbeitet.
# Diese Einschränkung kann nur einmal in einem DisabledAlgorithm
# -Ausdruck verwendet werden.
# Beispiel: Um die Verwendung von RSA 2048-Bit-Zertifikaten nach dem 3. Februar 2020 zu verweigern,
# verwenden Sie Folgendes: "RSA keySize == 2048 & denyAfter 2020-02-03"
#
# UsageConstraint:
# Verwendung [TLSServer] [TLSClient] [SignedJAR]
# Diese Einschränkung verbietet den angegebenen Algorithmus für
# eine bestimmte Verwendung. Dies sollte verwendet werden, wenn das Deaktivieren eines Algorithmus
# für alle Verwendungen nicht praktikabel ist. „TLSServer“ schränkt den Algorithmus
# in TLS-Serverzertifikatsketten ein, wenn eine Serverauthentifizierung durchgeführt wird
# . „TLSClient“ schränkt den Algorithmus im TLS-Client ein
# Zertifikatsketten, wenn die Clientauthentifizierung durchgeführt wird.
# „SignedJAR“ schränkt die Verwendung von Zertifikaten in signierten JAR-Dateien ein.
# Der Verwendungstyp folgt dem Schlüsselwort und mehr als ein Verwendungstyp kann sein
# muss mit einem Leerzeichen-Trennzeichen angegeben werden.
# Beispiel: „SHA1-Verwendung TLSServer TLSClient“
#
# Wenn ein Algorithmus mehr als eine Einschränkung erfüllen muss, muss er
# durch ein kaufmännisches Und-Zeichen „&“ getrennt werden. Um beispielsweise Zertifikate in einer
#-Kette einzuschränken, die an einem von der Verteilung bereitgestellten Vertrauensanker enden und
# RSA-Schlüssel enthalten, die kleiner oder gleich 1024 Bits sind, fügen Sie die folgende
#-Einschränkung hinzu: „RSA keySize <= 1024 & jdkCA".
#
# Alle DisabledAlgorithms-Ausdrücke werden in der in der Eigenschaft
# definierten Reihenfolge verarbeitet. Dies erfordert die Angabe niedrigerer Schlüsselgrößenbeschränkungen
# vor größeren Schlüsselgrößenbeschränkungen desselben Algorithmus. Zum Beispiel:
# „RSA keySize < 1024 & jdkCA, RSA keySize < 2048“.
#
# Hinweis: Die Algorithmusbeschränkungen gelten nicht für Vertrauensanker oder
# selbstsignierte Zertifikate.
#
# Hinweis: Diese Eigenschaft wird derzeit von der PKIX-Implementierung von Oracle verwendet. Es ist nicht garantiert, dass es von anderen Implementierungen untersucht und verwendet wird.
#
# Beispiel:
# jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & Nutzung TLSServer,
RSA keySize < 1024, DSA-Schlüsselgröße < 1024, EC-Schlüsselgröße < 224
#
# Legacy-Algorithmen für die Verarbeitung des Zertifizierungspfads (CertPath) und
# signierte JAR-Dateien.
#
# In manchen Umgebungen kann ein bestimmter Algorithmus oder eine bestimmte Schlüssellänge unerwünscht sein
#, ist aber noch nicht deaktiviert.
#
# Tools wie Keytool und Jarsigner geben möglicherweise Warnungen aus, wenn diese alten
# Algorithmen verwendet werden. Weitere Informationen finden Sie in den Manpages dieser Tools.
#
# Die Syntax ist dieselbe wie bei den Sicherheitseigenschaften „jdk.certpath.disabledAlgorithms“ und
# „jdk.jar.disabledAlgorithms“.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenz
#-Implementierung verwendet. Es kann nicht garantiert werden, dass es von anderen
# Implementierungen untersucht und verwendet wird.
jdk.security.legacyAlgorithms=SHA1,
RSA keySize < 2048, DSA-Schlüsselgröße < 2048

#
# Algorithmusbeschränkungen für signierte JAR-Dateien
#
# In manchen Umgebungen können bestimmte Algorithmen oder Schlüssellängen unerwünscht sein
# für die Validierung signierter JAR. Beispielsweise gilt „MD2“ im Allgemeinen nicht mehr
# als sicherer Hash-Algorithmus. In diesem Abschnitt wird der
# Mechanismus zum Deaktivieren von Algorithmen basierend auf dem Algorithmusnamen und/oder der Schlüssellänge beschrieben.
# JARs, die mit einem der deaktivierten Algorithmen oder Schlüsselgrößen signiert sind, werden
# als nicht signiert behandelt.
#
# Die Syntax der deaktivierten Die Algorithmuszeichenfolge wird wie folgt beschrieben:
# DisabledAlgorithms:
# " DisabledAlgorithm { , DisabledAlgorithm } "
#
# DisabledAlgorithm:
# AlgorithmName [Constraint] { '&' Constraint }
#
# AlgorithmName :
# (siehe unten)
#
# Einschränkung:
# KeySizeConstraint | DenyAfterConstraint
#
# KeySizeConstraint:
# keySize Operator KeyLength
#
# DenyAfterConstraint:
# denyAfter YYYY-MM-DD
#
# Operator:
# b1c9ed4f687c0238205d15575a6578ff= | >
#
# KeyLength:
# Ganzzahliger Wert der Schlüssellänge des Algorithmus in Bits
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenz
#-Implementierung verwendet. Es kann nicht garantiert werden, dass es von anderen Implementierungen untersucht und verwendet wird.
#
# Syntaxbeschreibungen finden Sie unter „jdk.certpath.disabledAlgorithms“. 1024,
DSA-Schlüsselgröße a28358264e1169c2f9589dcea83ec4ca/conf/security/policy/, das angepasst werden kann.
# Weitere Informationen finden Sie in der Datei 63b3ee7e72479f6360d4c7e4b3af780a/conf/security/policy/README.txt oder im Java-Sicherheitsleitfaden bzw. in der JCA-Dokumentation. Es wird Ihnen empfohlen, sich an Ihren Export-/Importkontrollberater zu wenden ODER ANWALT
#, UM DIE GENAUEN ANFORDERUNGEN ZU BESTIMMEN.
#
# [1] Bitte beachten Sie, dass die JCE für Java SE, einschließlich des JCE-Frameworks,
# kryptografische Richtliniendateien und Standard-JCE-Anbieter, die mit
# der Java SE bereitgestellt werden, vorhanden sind wurde vom US Bureau of Industry and Security geprüft und für den Export als Massenmarkt freigegeben.
# Verschlüsselungsartikel durch andere Implementierungen.
#
crypto.policy=unlimited

#
# Die Richtlinie für den sicheren Validierungsmodus der XML-Signatur. Der Modus wird
# aktiviert, indem die Eigenschaft „org.jcp.xml.dsig.secureValidation“ mit der Methode javax.xml.crypto.XMLCryptoContext.setProperty() auf
# true gesetzt wird,
# oder indem der Code mit einem SecurityManager ausgeführt wird .
#
# Policy:
# Constraint {"," Constraint }
# Constraint:
# AlgConstraint | MaxTransformsConstraint | MaxReferencesConstraint |
# ReferenceUriSchemeConstraint | KeySizeConstraint | OtherConstraint
# AlgConstraint
# "disallowAlg" Uri
# MaxTransformsConstraint:
# "maxTransforms" Integer
# MaxReferencesConstraint:
# "maxReferences" Integer
# ReferenceUriSchemeCon Straint:
# "disallowReferenceUriSchemes" String { String }
# KeySizeConstraint:
# " minKeySize" KeyAlg Integer
# OtherConstraint:
# "noDuplicateIds" | „noRetrievalMethodLoops“
#
# Für AlgConstraint ist Uri der Algorithmus-URI-String, der nicht zulässig ist.
# Weitere Informationen zu Algorithmen finden Sie in der XML-Signaturempfehlung.
# URI-Identifikatoren. Für KeySizeConstraint ist KeyAlg der Standardalgorithmus
# Name des Schlüsseltyps (z. B. „RSA“). Wenn MaxTransformsConstraint,
# MaxReferencesConstraint oder KeySizeConstraint (für denselben Schlüsseltyp) mehr als einmal angegeben wird, wird nur der letzte Eintrag erzwungen.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet. Es kann nicht garantiert werden, dass es von anderen Implementierungen untersucht und verwendet wird http://www.w3.org/2001/04/xmldsig-more#rsa-md5,
disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,
disallowAlg http: //www.w3.org/2001/04/xmldsig-more#md5,
maxTransforms 5,
maxReferences 30,
disallowReferenceUriSchemes-Datei http https,
minKeySize RSA 1024,
minKeySize DSA 1024,
minKeySize EC 224,
noDuplicateIds,
noRetrievalMethodLoops

#
# Systemweiter Serialisierungsfilter
#
# Ein Filter, falls konfiguriert, wird von java.io.ObjectInputStream während
# Deserialisierung verwendet, um den Inhalt des Streams zu überprüfen.
# Ein Filter wird als eine Folge von Mustern konfiguriert , jedes Muster wird entweder
# mit dem Namen einer Klasse im Stream abgeglichen oder definiert ein Limit.
# Muster werden durch „;“ getrennt. (Semikolon) Enthält ein „=", wird ein Grenzwert festgelegt.
# Wenn ein Grenzwert mehr als einmal vorkommt, wird der letzte Wert verwendet.
# Grenzwerte werden vor den Klassen überprüft, unabhängig von der Reihenfolge in der
# Musterfolge.
# Wenn einer von Die Grenzwerte werden überschritten, der Filterstatus ist ABGELEHNT.
#
# max Depth=value – die maximale Tiefe eines Diagramms
# maxrefs=value – die maximale Anzahl interner Referenzen
# maxbytes=value – die maximale Anzahl von Bytes im Eingabestrom
# maxarray=Wert – die maximal zulässige Array-Länge
#
# Andere Muster, von links nach rechts, stimmen mit dem Klassen- oder Paketnamen überein, wie
# von Class.getName zurückgegeben.
# Wenn die Klasse ein Array-Typ ist, Die abzugleichende Klasse oder das Paket ist der
# Elementtyp.
# Arrays mit einer beliebigen Anzahl von Dimensionen werden genauso behandelt wie der Elementtyp.
# Beispielsweise lehnt ein Muster „!example.Foo“ die Erstellung eines beliebigen ab Instanz oder
# Array von example.Foo.
#
# Wenn das Muster mit „!“ beginnt, lautet der Status ABGELEHNT, wenn das verbleibende
# Muster übereinstimmt; andernfalls ist der Status ERLAUBT, wenn das Muster übereinstimmt.
# Wenn das Muster „/“ enthält, ist das nicht leere Präfix bis zum „/“ der
# Modulname;
# wenn der Modulname mit dem Modulnamen des übereinstimmt class then
# das verbleibende Muster wird mit dem Klassennamen abgeglichen.
# Wenn kein „/“ vorhanden ist, wird der Modulname nicht verglichen.
# Wenn das Muster mit „.**“ endet, stimmt es mit jeder Klasse im Paket überein und alle
# Unterpakete.
# Wenn das Muster mit „.*“ endet, stimmt es mit jeder Klasse im Paket überein.
# Wenn das Muster mit „*“ endet, stimmt es mit jeder Klasse mit dem Muster als
# Präfix überein.
# Wenn das Muster mit dem Klassennamen übereinstimmt, stimmt es überein.
# Andernfalls lautet der Status UNDECIDED.
#
#jdk.serialFilter=pattern;pattern

#
# RMI Registry Serial Filter
#
# Das Filtermuster verwendet das gleiche Format wie jdk.serialFilter.
# Dieser Filter kann den integrierten Filter überschreiben, falls zusätzlich Typen müssen
# in der RMI-Registrierung zugelassen oder abgelehnt werden oder um Grenzwerte zu verringern, aber nicht
# um Grenzwerte zu erhöhen.
# Wenn die Grenzwerte (max Depth, maxrefs oder maxbytes) überschritten werden, Das Objekt wird abgelehnt.
#
# Jeder Nicht-Array-Typ ist zulässig oder abgelehnt, wenn er mit einem der Muster übereinstimmt,
# von links nach rechts ausgewertet und ansonsten zulässig. Arrays jedes Komponententyps, einschließlich Unterarrays und Arrays von Grundelementen, sind zulässig.
#
# Array-Konstruktion eines beliebigen Komponententyps, einschließlich Unterarrays und Arrays von Grundelementen, sind zulässig, es sei denn, die Länge ist größer als das Maxarray-Limit.
# Der Filter wird auf jedes Array-Element angewendet.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet.# 🎜🎜## Es kann nicht garantiert werden, dass es von anderen Implementierungen untersucht und verwendet wird.
#
# Der eingebaute Filter ermöglicht Unterklassen von zulässigen Klassen und
# kann ungefähr als Muster dargestellt werden :#?? 🎜## java.lang.Number;
# java.lang.reflect.Proxy;
# java.rmi.Remote;
# sun.rmi.server.UnicastRef;
# sun.rmi.server.RMIClientSocketFactory;
# sun.rmi.server.RMIServerSocketFactory;
# java.rmi.activation.ActivationID;
# java.rmi.server.UID#🎜🎜 ##
# RMI Distributed Garbage Collector (DGC) Serial Filter
#
# Das Filtermuster verwendet dasselbe Format wie jdk.serialFilter.
# Dieser Filter kann den integrierten Filter überschreiben wenn zusätzliche Typen
# vom RMI DGC zugelassen oder abgelehnt werden müssen.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet.
# Dies ist nicht der Fall Wird garantiert von anderen Implementierungen untersucht und verwendet.
#
# Der eingebaute DGC-Filter kann ungefähr als Filtermuster dargestellt werden:
#
#sun.rmi.transport.dgcFilter =
# java.rmi.server.ObjID;
# java.rmi.server.UID;
# java.rmi.dgc.VMID;
# java.rmi.dgc .Lease;
# max Depth=5;maxarray=10000

#
# JCEKS Encrypted Key Serial Filter
#
# Dieser Filter, falls konfiguriert, wird vom JCEKS KeyStore während der
# Deserialisierung des verschlüsselten Schlüsselobjekts verwendet, das in einem Schlüsseleintrag gespeichert ist.
# Wenn nicht konfiguriert oder das Filterergebnis UNDENTSCHEIDET ist (d. h. keines der Muster
# übereinstimmt), wird der von jdk.serialFilter konfigurierte Filter herangezogen.
#
# Wenn auch die Systemeigenschaft jceks.key.serialFilter angegeben ist, ersetzt sie#🎜 🎜## der hier definierte Sicherheitseigenschaftswert.
#
# Das Filtermuster verwendet dasselbe Format wie jdk.serialFilter. Das Standardmuster
# lässt java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type,
# und javax.crypto.spec.SecretKeySpec zu und lehnt alle anderen ab.#🎜 🎜#jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep;
java.base/java.security.KeyRep$Type;java.base/javax. crypto.spec.SecretKeySpec;!*

# Die Iterationsanzahl, die für die passwortbasierte Verschlüsselung (PBE) in JCEKS
# Keystores verwendet wird. Werte im Bereich von 10.000 bis 5.000.000 gelten als gültig.
# Wenn der Wert außerhalb dieses Bereichs liegt, keine Zahl ist oder nicht angegeben ist;
# wird ein Standardwert von 200.000 verwendet.#🎜🎜 ##
# Wenn auch die Systemeigenschaft jdk.jceks.iterationCount angegeben ist, ersetzt sie
# den hier definierten Sicherheitseigenschaftswert.
#
#jdk.jceks.iterationCount = 200000

#
# PKCS12 KeyStore-Eigenschaften
#
# Die folgenden Eigenschaften werden, sofern konfiguriert, von der PKCS12 KeyStore
#-Implementierung während der Erstellung eines neuen Keystores verwendet. Mehrere der
#-Eigenschaften können auch beim Ändern eines vorhandenen Keystores verwendet werden. Die
#-Eigenschaften können von einer KeyStore-API überschrieben werden, die ihre eigenen
#-Algorithmen und Parameter angibt.
#
# Wenn ein vorhandener PKCS12-Keystore geladen und dann gespeichert wird, werden der Algorithmus und
#-Parameter zum Generieren des vorhandenen Mac verwendet wiederverwendet. Wenn der vorhandene
# Keystore keinen Mac hat, wird beim Speichern kein Mac erstellt. Wenn mindestens ein Zertifikat im vorhandenen Schlüsselspeicher vorhanden ist, werden der Algorithmus und die Parameter, die zum Verschlüsseln des letzten Zertifikats im vorhandenen Schlüsselspeicher verwendet wurden, wiederverwendet, um alle Zertifikate beim Speichern zu verschlüsseln. Wenn das letzte Zertifikat
# im vorhandenen Keystore nicht verschlüsselt ist, werden alle Zertifikate
# unverschlüsselt gespeichert. Wenn im vorhandenen Schlüsselspeicher kein Zertifikat vorhanden ist, wird jedes neu hinzugefügte Zertifikat mithilfe von „keystore.pkcs12.certProtectionAlgorithm“ und „keystore.pkcs12“ verschlüsselt (oder unverschlüsselt gespeichert, wenn der Wert des Algorithmus „NONE“ lautet). „certPbeIterationCount“-Werte, die hier definiert sind. Vorhandene private
# und geheime Schlüssel werden nicht geändert. Neu festgelegte private und geheime Schlüssel werden
# mit den hier definierten Werten „keystore.pkcs12.keyProtectionAlgorithm“ und
# „keystore.pkcs12.keyPbeIterationCount“ verschlüsselt.
#
# Um neue Algorithmen und Parameter anzuwenden Um alle Einträge in einem
# bestehenden Keystore zu löschen, kann man einen neuen Keystore erstellen und Einträge im
# bestehenden Keystore zum neuen Keystore hinzufügen. Dies kann durch Aufrufen des Befehls
# „keytool -importkeystore“ erreicht werden.
#
# Wenn auch eine Systemeigenschaft mit demselben Namen angegeben wird, ersetzt sie den hier definierten Wert der Sicherheitseigenschaft.
#
# Wenn die Eigenschaft auf einen unzulässigen Wert gesetzt ist,
# eine Iterationszahl, die keine positive Ganzzahl ist, oder ein unbekannter Algorithmus
# Name, wird eine Ausnahme ausgelöst, wenn die Eigenschaft verwendet wird.
# Wenn die Eigenschaft nicht gesetzt oder leer ist, a Es wird der Standardwert verwendet.
#
# Hinweis: Diese Eigenschaften werden derzeit von der JDK-Referenzimplementierung verwendet.
# Es wird nicht garantiert, dass sie von anderen Implementierungen überprüft und verwendet werden.

# Der Algorithmus, der zum Verschlüsseln eines Zertifikats verwendet wird. Dies kann jeder Nicht-Hmac-PBE-Algorithmus sein, der im Abschnitt „Cipher“ der Java Security Standard-Algorithmusnamensspezifikation definiert ist. Bei der Einstellung „NONE“ wird das Zertifikat
# nicht verschlüsselt. Der Standardwert ist „PBEWithHmacSHA256AndAES_256“.
#keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256

# Die Iterationsanzahl, die der PBE-Algorithmus beim Verschlüsseln eines Zertifikats verwendet.
# Dieser Wert muss eine positive Ganzzahl sein. Der Standardwert ist 10000.
#keystore.pkcs12.certPbeIterationCount = 10000

# Der Algorithmus, der zum Verschlüsseln eines privaten oder geheimen Schlüssels verwendet wird. Dies kann jeder Nicht-Hmac-PBE-Algorithmus sein, der im Abschnitt „Cipher“ der Java Security Standard Algorithm Names Specification definiert ist. Der Wert darf nicht „NONE“ sein.
# Der Standardwert ist „PBEWithHmacSHA256AndAES_256“.
#keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
# Die vom PBE-Algorithmus verwendete Iterationsanzahl beim Verschlüsseln eines privaten Schlüssels
# oder eines geheimen Schlüssels . Dieser Wert muss eine positive ganze Zahl sein. Der Standardwert
# ist 10000.
#keystore.pkcs12.keyPbeIterationCount = 10000

# Der Algorithmus, der zur Berechnung der optionalen MacData am Ende einer PKCS12
#-Datei verwendet wird. Dies kann jeder HmacPBE-Algorithmus sein, der im Mac-Abschnitt der
# Java Security Standard Algorithm Names Specification definiert ist. Bei der Einstellung „NONE“ wird
# kein Mac generiert. Der Standardwert ist „HmacPBESHA256“.
#keystore.pkcs12.macAlgorithm = HmacPBESHA256

# Die vom MacData-Algorithmus verwendete Iterationsanzahl. Dieser Wert muss eine
# positive Ganzzahl sein. Der Standardwert ist 10000.
#keystore.pkcs12.macIterationCount = 10000

#
# Erweiterte Ausnahmemeldungsinformationen
#
# Standardmäßig sollten Ausnahmemeldungen keine potenziell vertraulichen
# Informationen wie Dateinamen, Hostnamen oder Port enthalten Zahlen. Diese Eigenschaft
# akzeptiert einen oder mehrere durch Kommas getrennte Werte, von denen jeder eine
# Kategorie erweiterter Ausnahmemeldungsinformationen darstellt, die aktiviert werden sollen. Bei den Werten wird die Groß-/Kleinschreibung nicht beachtet. Führende und nachfolgende Leerzeichen, die jeden Wert umgeben,
# werden ignoriert. Unbekannte Werte werden ignoriert.
#
# HINWEIS: Seien Sie vorsichtig, bevor Sie diese Eigenschaft festlegen. Durch das Festlegen dieser Eigenschaft werden vertrauliche Informationen in Ausnahmen verfügbar gemacht, die beispielsweise an nicht vertrauenswürdigen Code weitergegeben oder in Stack-Traces ausgegeben werden könnten, die unbeabsichtigt offengelegt und öffentlich zugänglich gemacht werden network.
#
# Die Kategorien sind:
#
# hostInfo – Von java.net.Socket und den Socket-Typen in java.nio ausgelöste IOExceptions Das .channels-Paket enthält erweiterte Ausnahmen
# Nachrichteninformationen
#
# jar - ermöglicht detailliertere Informationen in den ausgelösten IOExceptions
# von Klassen im java.util.jar-Paket# 🎜🎜##
# Die Eigenschaftseinstellung in dieser Datei kann durch eine Systemeigenschaft
# mit demselben Namen, derselben Syntax und denselben möglichen Werten überschrieben werden.
#
# jdk.includeInExceptions=hostInfo,jar

#
# Deaktivierte Mechanismen für die Simple Authentication and Security Layer (SASL)
#
# Deaktivierte Mechanismen werden nicht ausgehandelt von Sowohl SASL-Clients als auch -Server.
# Diese Mechanismen werden ignoriert, wenn sie im Argument „mechanisms“
# von „Sasl.createSaslClient“ oder im Argument „mechanism“ von
# angegeben werden. Sasl.createSaslServer".
#
# Der Wert dieser Eigenschaft ist eine durch Kommas getrennte Liste von SASL-Mechanismen.
# Bei den Mechanismen wird die Groß-/Kleinschreibung beachtet. Leerzeichen um die Kommas werden ignoriert.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet.
# Es kann nicht garantiert werden, dass sie von anderen Implementierungen untersucht und verwendet wird.#🎜 🎜##
# Beispiel:
# jdk.sasl.disabledMechanisms=PLAIN, CRAM-MD5, DIGEST-MD5
jdk.sasl.disabledMechanisms=

## 🎜🎜## Richtlinien für das Misstrauen gegenüber Zertifizierungsstellen (CAs).
#
# Dies ist ein durch Kommas getrennter Wert aus einer oder mehreren Zeichenfolgen, bei denen die Groß-/Kleinschreibung beachtet werden muss. Jede(r)
# stellt eine Richtlinie für dar Bestimmen, ob einer Zertifizierungsstelle nicht vertraut werden sollte.
# Die unterstützten Werte sind:
#
# SYMANTEC_TLS : Misstrauen Sie TLS-Serverzertifikaten, die von einer Symantec
# Stammzertifizierungsstelle verankert und nach dem 16. April ausgestellt wurden , 2019, sofern nicht von einer der folgenden untergeordneten Zertifizierungsstellen ausgestellt, die ein späteres Misstrauensdatum haben:
# 1. Apple IST CA 2 – G1, SHA-256-Fingerabdruck:
# AC2B922ECFD5E01711772FEA8ED372DE9D1 E2245FCE3F57A9CDBEC77296A424B#🎜 🎜## Misstrauen nach dem 31. Dezember 2019.
# 2. Apple IST CA 8 – G1, SHA-256 Fingerabdruck:
# A4FE7C7F15155F3F0AEF7AAA83CF6E06DEB97CA3F909DF 920AC1490882D488ED
# Misstrauen nach dem 31. Dezember 2019.#🎜🎜 ##
# Führende und nachfolgende Leerzeichen um jeden Wert herum werden ignoriert.
# Unbekannte Werte werden ignoriert. Wenn die Eigenschaft auskommentiert oder auf den
# leeren String gesetzt ist, werden keine Richtlinien erzwungen.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet.
# Es kann nicht garantiert werden, dass es von anderen SE-Implementierungen unterstützt wird. Außerdem überschreibt diese Eigenschaft keine anderen Sicherheitseigenschaften, die Zertifikate wie jdk.tls.disabledAlgorithms oder jdk.certpath.disabledAlgorithms einschränken können. Diese Einschränkungen werden auch dann noch durchgesetzt, wenn diese Eigenschaft nicht aktiviert ist Kanonisierung
#
# Diese Sicherheitseigenschaft bestimmt, wie das Pfadargument verarbeitet und gespeichert wird
# beim Erstellen eines FilePermission-Objekts. Wenn der Wert auf „true“ gesetzt ist, wird das Pfadargument
# kanonisiert und FilePermission-Methoden (z. B. impliziert,
# gleich und hashCode) werden basierend auf diesem kanonisierten Ergebnis implementiert.
# Andernfalls , das Pfadargument ist nicht kanonisiert und FilePermission-Methoden werden
# basierend auf der ursprünglichen Eingabe implementiert. Weitere Einzelheiten finden Sie im Implementierungshinweis der Klasse „FilePermission“. hier definiert.
#
# Der Standardwert für diese Eigenschaft ist false.
#
jdk.io.permissionsUseCanonicalPath=false

#
# Richtlinien für den Proxy_impersonator Kerberos-Cache-Konfigurationseintrag
#
# Der Proxy_impersonator-Cache-Konfigurationseintrag gibt an, dass es sich bei dem Ccache
# um einen synthetischen delegierten Berechtigungsnachweis zur Verwendung mit handelt S4U2Proxy durch einen Zwischenserver. Die Ccache-Datei sollte auch das TGT dieses Servers und
# ein Beweisticket vom Standardprinzipal des Ccaches zu diesem Server enthalten.
#
# Diese Sicherheitseigenschaft bestimmt, wie Java diese Konfiguration verwendet Eintrag.
# Es gibt 3 mögliche Werte:
#
# no-impersonate – Ignorieren Sie diesen Konfigurationseintrag und handeln Sie immer als
# der Eigentümer des TGT (falls vorhanden). ) Fallback auf No-Imitate.
#
# always-impersonate - Immer imitieren, wenn dieser Konfigurationseintrag vorhanden ist.
# tial wird aus dem Cache gelesen .
#
# Der Standardwert ist „always-impersonate“.
#
# Wenn auch eine Systemeigenschaft mit demselben Namen angegeben wird, ersetzt sie die
# Sicherheitseigenschaftswert hier definiert.
#
#jdk.security.krb5.default.initiate.credential=always-impersonate

#
# Trust Anchor-Zertifikate – CA Basic Constraint check
#
# Wenn
# sie außerdem eine Schlüsselverwendungserweiterung enthalten, muss das keyCertSign-Bit gesetzt sein. Diese standardmäßig aktivierten Prüfungen können aus Gründen der Abwärtskompatibilität mit den Eigenschaften jdk.security.allowNonCaAnchor System und Sicherheit deaktiviert werden. Für den Fall, dass beide Eigenschaften gleichzeitig gesetzt sind, hat der
# Systemwert Vorrang. Der Standardwert der Eigenschaft ist „false“.
#
#jdk.security.allowNonCaAnchor=true

#
# Der Standardzeichensatzname (java. nio.charset.Charset.forName())
# zum Konvertieren von TLS-ALPN-Werten zwischen Byte-Arrays und Strings.
# Frühere Versionen des JDK verwenden möglicherweise UTF-8 als Standardzeichensatz. Wenn
# Interoperabilitätsprobleme auftreten, kann es hilfreich sein, diese Eigenschaft auf UTF-8
# zu setzen.
#
# jdk.tls.alpnCharset=UTF-8
jdk .tls.alpnCharset=ISO_8859_1

#
# JNDI Object Factories Filter
#
# Dieser Filter wird von der JNDI-Laufzeit verwendet, um den Satz von Objekt-Factory-Klassen zu steuern
#, mit dem Objekte aus Objektreferenzen instanziiert werden können, die von
# Benennungs-/Verzeichnissystemen zurückgegeben werden. Die von der Referenzinstanz benannte Factory-Klasse wird mit diesem Filter abgeglichen. Die Filtereigenschaft unterstützt musterbasierte Filtersyntax
# mit demselben Format wie jdk.serialFilter.
#
# Jedes Muster wird mit dem Fabrikklassennamen abgeglichen, um es zuzulassen oder nicht zuzulassen#🎜🎜 ## Instanziierung. Der Zugriff auf eine Factory-Klasse ist zulässig, es sei denn, der Filter gibt
# REJECTED zurück.
#
# Hinweis: Diese Eigenschaft wird derzeit von der JDK-Referenzimplementierung verwendet.
# Dies ist nicht der Fall Wird garantiert von anderen Implementierungen untersucht und verwendet.
#
# Wenn auch die Systemeigenschaft jdk.jndi.object.factoriesFilter angegeben ist, ersetzt sie
# den hier definierten Sicherheitseigenschaftswert. Der Standardwert der Eigenschaft ist „*“.
#
# Der Standardmusterwert ermöglicht es jeder Objekt-Factory-Klasse, die durch die Referenz
# Instanz angegeben wird, das referenzierte Objekt neu zu erstellen.
#jdk.jndi.object.factoriesFilter=*

Das obige ist der detaillierte Inhalt vonNach Java8 (291) ist TLS1.1 deaktiviert und JDBC kann keine Verbindung zu SqlServer2008 über SSL herstellen. Wie kann das Problem gelöst werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme：

Dieser Artikel ist reproduziert unter:yisu.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen

Vorheriger Artikel：So integrieren Sie die Drools-Regel-Engine in SpringBoot2Nächster Artikel：So integrieren Sie die Drools-Regel-Engine in SpringBoot2

In Verbindung stehende Artikel

Mehr sehen