-
Notifications
You must be signed in to change notification settings - Fork 54
/
amazon-corretto-crypto-provider.security
67 lines (64 loc) · 3.32 KB
/
amazon-corretto-crypto-provider.security
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#
# List of providers and their preference orders
# Note that we can't just insert ours at the top - we need to restate all
# providers that are being shifted down to a different index (which is to say,
# all of them).
#
# Also, JDK9+ handles this list very differently from JDK8.
# JDK8 requires that providers be specified using fully-qualified class names.
# JDK9+ supports fully-qualified class names if and only if the module containing the class exports it.
# For modules which don't export the class in question, the provider must be specified used its "Provider Name".
# Many of the providers which come as part of the JDK (e.g., SunEC) are not exported from their modules and
# thus must be specified using their Provider Name rather than their class name.
#
# This means that for most of these providers there is no single way to specify them which works for both JDK8 and JDK9+.
#
# Rather than have two different copies of this file (one for JDK8 and one for JDK9+) which users must select between
# depending on which JDK8 they are running, we have created a single merged listing.
# ACCP is listed first as a fully-qualified class (because it is exported by the module and will work on all systems).
# After that we alternate between the fully-qualified class (for JDK8) and the provider name for those which
# are not exported by the module for JDK9+.
# Each JDK will ignore entries it doesn't understand.
# JDK8 will determine that there is no class with the short provider name and skip it.
# JDK9+ will determine that the fully-qualified class is not visible and will skip it.
#
# Some providers are specified by name only, meaning that they may not work
# properly on JDK 8. In the case of the Apple provider, this is because our CI
# Mac images allowed duplicate installs of the Apple provider on Java 8. We use
# the name-only variant of the provider because the apple.security.AppleProvider
# is not exported from its module in JDK 11.
#
# This results in a single list with proper behavior on both JDK8 and JDK9+ systems
# for most providers.
security.provider.1=com.amazon.corretto.crypto.provider.AmazonCorrettoCryptoProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=sun.security.ec.SunEC
security.provider.5=SunEC
security.provider.6=com.sun.net.ssl.internal.ssl.Provider
security.provider.7=com.sun.crypto.provider.SunJCE
security.provider.8=sun.security.jgss.SunProvider
security.provider.9=SunJGSS
security.provider.10=com.sun.security.sasl.Provider
security.provider.11=SunSASL
security.provider.12=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.13=XMLDSig
security.provider.14=sun.security.smartcardio.SunPCSC
security.provider.15=SunPCSC
security.provider.16=JdkLDAP
security.provider.17=JdkSASL
security.provider.18=sun.security.mscapi.SunMSCAPI
security.provider.19=SunMSCAPI
security.provider.20=Apple
security.provider.21=SunPKCS11
#
# A list of known strong SecureRandom implementations.
#
# To help guide applications in selecting a suitable strong
# java.security.SecureRandom implementation, Java distributions should
# indicate a list of known strong implementations using the property.
#
# This is a comma-separated list of algorithm and/or algorithm:provider
# entries.
#
securerandom.strongAlgorithms=DEFAULT:AmazonCorrettoCryptoProvider,NativePRNGBlocking:SUN,DRBG:SUN