Notes on jdk.certpath.disabledAlgorithms

Brent Putman putmanb at georgetown.edu
Mon Jan 23 17:33:14 EST 2017



On 1/23/17 3:21 PM, Cantor, Scott wrote:
>> I was not able to set jdk.certpath.disabledAlgorithms as a system property
>> (i.e. -D), I don’t see any doc that that should work.
> You can set the PNRG property that way and that's also defined in that same file. I just assumed it would apply to any of them.


So nuts and bolts question:  Just to be clear,  what/how *exactly* are
you setting this way?

It rang a bell for me in the other place where you mentioned, so I just
looked at a new app server I set up recently and there I am indeed
effectively setting the PRNG entropy source via the system property
"java.security.egd" via a -D.

So I looked at java.security and the conceptual discrepancy became clear
from the comments there.  The java.security property that sets this (I
think technically for the "Sun" provider, that provides their impl of
SecureRandom) is actually "securerandom.source".  However, that specific
one can be overriden with the system property "java.security.egd".  An
excerpt from the comments for "securerandom.source":

# Sun Provider SecureRandom seed source.
#
# Select the primary source of seed data for the "SHA1PRNG" and
# "NativePRNG" SecureRandom implementations in the "Sun" provider.
# (Other SecureRandom implementations might also use this property.)
#
# ...snip...
#
# The entropy gathering device can also be specified with the System
# property "java.security.egd". For example:
#
#   % java -Djava.security.egd=file:/dev/random
MainClass                                                                                                                                                                         

#
# Specifying this System property will override the
# "securerandom.source" Security property.


So that all jibes with what I earlier vaguely thought was the case,
which was:  The props in java.security are not system properties.  They
are properties specific to the java.security.Security security provider
service class, which may be used by loaded security providers.  In
general you can't specify them individually as system properties.  As we
see for the SecureRandom seed, specific security providers that are
loaded *can* use system properties as overrides (or maybe even as the
sole way to set something), but that's going to be on a
provider-specific basis. 

Looking at the source for java.security.Security seems to confirm: 
These is no use of System.getProperty and friends there, except for the
system property "java.security.properties", which allows specifying a
full file of properties, which we already knew from Tom (and for getting
the actual "jre/lib/security" path relative to java.home, but that's not
user input).

FYI, the only other comments re use of system properties there are for
allowing a system prop for security manager policy:

# whether or not we allow an extra policy to be passed on the command line
# with -Djava.security.policy=somefile. Comment out this line to disable
# this feature.
policy.allowSystemProperty=true



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170123/c8fc7317/attachment-0001.html>


More information about the dev mailing list