What is the correct way to disable SSLv3 on Orbix 6.3 services? I am new to Orbix and I was recently given an environment to support on one of our servers. My task is to disable SSLv3 which is still supported on the environment.
Per the documentation on the linkbelow, I have updated the .cfg files within our domains to include the following lines:
policies:iiop_tls:mechanism_policy:protocol_version = ["TLS_V1_2"];
policies:https:mechanism_policy:protocol_version = ["TLS_V1_2"];
Our environment consists of two configuration domains.
When I make the changes to the first domain, for the config_rep, the changes work and SSLv3 is disabled as expected.
When I make the changes to the second domain, for the locator, node_daemon and naming services. SSLv3 is still enabled.
Verified with the command line: openssl s_client -connect localhost:3077 -ssl3 reports back with Secure Renegotiation IS supported
The .cfg domain files are nearly identical.
https://community.microfocus.com/microfocus/corba/visibroker_-_world_class_middleware/w/knowledge_base/28339/best-practices-for-implementing-security-using-micro-focus-corba-products
I was eventually able to figure this out.
It turns out that Orbix can have configurations that are already loaded into their database. In my example, one of the configuration files wasn't being loaded. If the configuration file isn't being used. you can update the TLS value of your Orbix service with the following Orbix command:
./itadmin variable modify -type string -value "1.1" policies:iiop:server_version_policy
Once this command is entered, it will force your Orbix service to TLS 1.1 and higher
Related
How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)
I'm hoping some of you may be able to help me with setting up SSL on my fuseki server. I've been battling with it for a few days now and am running out of possible solutions!
OS: RHEL 8.5 (Ootpa)
Fuseki: Version 4.2.0
Currently running as system service with:
ExecStart=/home/fuseki/apache-jena-fuseki-4.2.0/fuseki-server -v -tdb2 -update -config=/home/fuseki/fuseki_data/config.ttl
This is the manual I've been working with- https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
The following are the provided arguments to add in the startup sequence of fuseki-server.
–https=SETUP [Name of file for certificate details.]
& –httpsPort=PORT [The port for https. Default: 3043]
The --https argument names a file in JSON which includes the name of
the certificate file and password for the certificate.
The issue is that no matter how I phrase the arguments the process returns "fuseki-server[9469]: Unknown argument: https" in the journalctl logs.
I have tried -https=dir, --https=dir, & -httpsConf=dir (where dir is the directory to my cert_details.json file).
Based on the docs https should have native support but when I check fuseki-server -help there is no mention of an https argument. I have created a .jks from my cert, have set the correct file permissions, and have allowed 3043.
I have also located the block of code in fuseki that resolves the keystore and passwd from the .json file (which led me to try using -httpsConf=)
private void setHttpsCert(String filename) {
try {
JsonObject httpsConf = JSON.read(filename);
Path path = Path.of(filename).toAbsolutePath();
String keystore = httpsConf.get("keystore").getAsString().value();
// Resolve relative to the https setup file.
this.httpsKeystore = path.getParent().resolve(keystore).toString();
this.httpsKeystorePasswd = httpsConf.get("passwd").getAsString().value();
Not sure what I'm missing here. For what it's worth I'm a chemist and I definitely don't know java all that well so it very well could be me being stupid. Any suggestions/knowledge would be greatly appreciated.
there are two ways to get HTTPS+Fuseki:
The document referred to is for the jar file here: https://repo1.maven.org/maven2/org/apache/jena/jena-fuseki-server/4.2.0/jena-fuseki-server-4.2.0.jar, not the jar in the apache-jena-fuseki download. (BTW It does not have the UI.)
The one in the apache-jena-fuseki can be use HTTPS by using a Jetty configuration using --jetty=jetty.xml (https://www.eclipse.org/jetty/documentation/current/jetty-xml-config.html) -- example: https://github.com/apache/jena/blob/main/jena-fuseki2/examples/fuseki-jetty-https.xml (which will need modifying).
I am following the directions here: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway.
When I create the certificates using OpenSSL and the 'New-CACertsEdgeDevice myGateway' commands, I end up with an Elliptical Curve based private key which fails when I configure the edge gateway with the message
"Currently RSA is only supported".
I modified the New-CACertsCertChain script in ca-certs.ps1 (set the $useEcc var to $false) and reran. The script succeeds, but now the New-CACertsEdgeDevice script fails with:
New-SelfSignedCertificate : Cannot convert 'System.Object[]' to the
type 'Microsoft.CertificateServices.Commands.Certificate' required by
parameter 'Signer'. Specified method is not supported.
Any idea what I am doing wrong?
I found an answer to this, although I am still not sure of the root cause.
These steps allowed me to create certificates that worked...
I kept the change I made to the New-CACertsCertChain (mentioned above)
I erased all the previous certs from the machine cert store
Then I closed the existing PowerShell console and started a new admin one.
I installed OpenSSL from here: https://sourceforge.net/projects/openssl/ # this directory: C:\utils\openssl\bin
I set up the environment paths as follows:
$ENV:PATH += ";C:\utils\openssl\bin"
$ENV:OPENSSL_CONF="C:\utils\openssl\bin\openssl.cnf"
After that I continued with the articles directions and it worked. I did get a warning about not finding C:/OpenSSL/openssl.cnf, but I ignored it.
I do not think you are doing anything wrong.
It appears that there is a problem with the powershell scripts. The good news is that there is a fix to the instructions at the Azure IoT C SDK GitHub branch CACertToolEdge which you can sync out and re-try.
I have filed an issue here: https://github.com/Azure/azure-iot-sdk-c/issues/337 to have this corrected.
Edit:
Jan 09 2018: It appears that the scripts have fixed and you shouldn't run into this specific problem.
NOTE: If you want to see the behaviour of this demo app, just go to www.collaborativepowernowinternational.us. Here, select the testssl.PersonController, and you may create a person. Then go and edit the person, where the SSL channel is designated, which will give a redirect loop.
It seems like with Jetty 9 more configuration items went into the start.ini file, I have version 9.05.
In order to test the most basic SSL/https, I am uncommenting the following lines in start.ini:
#===========================================================
# SSL Context
# Create the keystore and trust store for use by
# HTTPS and SPDY
#-----------------------------------------------------------
jetty.keystore=etc/keystore
jetty.keystore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.keymanager.password=OBF:1u2u1wml1z7s1z7a1wnl1u2g
jetty.truststore=etc/keystore
jetty.truststore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.secure.port=8443
etc/jetty-ssl.xml
#===========================================================
# HTTPS Connector
# Must be used with jetty-ssl.xml
#-----------------------------------------------------------
jetty.https.port=8443
etc/jetty-https.xml
No other Jetty configuration changes. I then built the most basic Grails app (has a Person class) where I set certain controller actions to secure, which works fine on my development machine using an older built in Jetty version (that Grails includes). This is done simply by including spring-security-core and then adding the following lines to a configuration file:
grails.plugins.springsecurity.secureChannel.definition = [
'/person/list': 'REQUIRES_INSECURE_CHANNEL',
'/person/delete/**': 'REQUIRES_SECURE_CHANNEL',
'/person/edit/**': 'REQUIRES_SECURE_CHANNEL',
'/person/show': 'REQUIRES_INSECURE_CHANNEL'
]
grails.plugins.springsecurity.portMapper.httpPort=80
grails.plugins.springsecurity.portMapper.httpsPort=443
When I access the person/edit action I get a redirect loop in the browser (using deployed WAR file to Jetty 9 on dedicated CentOs 6 machine). This is using the provided keystore that comes with Jetty 9, just uncommenting the lines in start.ini to use it.
The main Jetty SSL configuration page I'm reading is here. What isn't clear to me is, is updating the start.ini file enough? If not, how exactly does one add the lines in jetty-https.xml described in this previous link, i.e. the lines:
<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
<Set name="KeyStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="KeyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="KeyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="TrustStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="TrustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
Not sure how to add them, but they also seem a duplicate of the start.ini file lines above.
Can you please help help me get the most basic Jetty SSL running? Thanks much.
If not familiar with Grails, one can simply download it, then create a domain class -- there is a command line option for this. Then give it fields String firstName, String lastName. Then there are commands to generate a controller and views for it -- this is all totally automatic. Then one adds the plugin, spring-security-core. In chapter 16/17 of this doc and as I have shown, when lists which controller actions are secure, such as person/edit.
You actually have enough here for just the Jetty portion of this to be working using the default trial keystore we ship in Jetty 9.0.6 distribution.
Simply the blurb you have above is enough to make SSL work within Jetty. I downloaded the 9.0.6 distribution and uncommented those lines and it works. Well, I had to go into the start.d/demo.ini file and remove the last two lines with etc/jetty-ssl.xml and etc/jetty-https.xml because they would get run twice...but I digress.
If you start up Jetty you can navigate to https://localhost:8443 and it will complain about being an untrusted certificate and then load up the jetty distribution page.
Based on that I would say this is likely some sort of grails configuration issue that I sadly don't know the answer too, sorry.
Starting Jetty 9.1, things have changed, and you have to follow the instructions in here for things to look correct, per Jetty developers. Moreover, you are not supposed to change/delete/edit anything in ${jetty.home}'s directories. Here's what you need to do for a self-signed certificate based SSL/HTTPS on Jetty 9.1+:
(a) set up your environment variable $JETTY_HOME to point to where you installed your jetty tar bundle, say /opt/jetty/.
(b) Create a new directory, /tmp/myJettyApp, point it to $JETTY_BASE in your environment.
(c) cd to $JETTY_BASE
(d) Follow instructions in here:
/home/sonny $ cd $JETTY_BASE
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
(e) Set your port if you'd like:
/home/sonny $ cd $JETTY_BASE;
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
(f) And now, run jetty:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar
you will see that HTTPS is running at port 8444. Now, if you want to make jetty listen in the traditional HTTPS port, you have to use sudo to run:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=443
/tmp/myJettyApp/ $ sudo java -jar $JETTY_HOME/start.jar
Note that this already does the self-signed certs etc. automagically.
Now, if you want to generate your own self-signed certificate (say, because you want to modify the validity to an arbitrary large or small value, depending on your needs), follow the instructions in here, generate a new self-signed cert using keytool and then place it in $JETTY_BASE/etc/ and modify the $JETTY_BASE/start.d/ssl.ini for jetty.sslContext.keyStorePassword and jetty.sslContext.keyManagerPassword respectively. BTW, for the last two ssl.ini passwords, you can use the obfuscated plain text password you used when you ran keytool or use the plain text ones. If you want to obfuscate them, run {jetty.home} $ java -cp lib/jetty-util-9.3.6.v20151106.jar org.eclipse.jetty.util.security.Password "MyInterestingAndAwesomePassword"
Hope this helps someone.
I tried to run grailsw, but the wrapper cannot connect to download grails-2.2.1-download.zip (creates a 0 byte file instead).
I need to use a proxy server to connect to the internet, where do I configure proxy settings for the Grails Wrapper?
After running grails wrapper, your project directory has a new subdirectory called wrapper, with a file grails-wrapper.properties. You can configure your proxy settings in there, with the following properties:
systemProp.http.proxyHost=
systemProp.http.proxyPort=
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=
I solved this problem for myself.
It is a two step process
1.a) Back up your JRE_HOME\lib\security folder. This is essential because the below steps might corrupt cacerts file under jre.
1.b) You need to install the ssl public key of Github.com to your local file system. To do that you have to use the InstallCert.java program( Link to InstallCert.java )
It is supposed to be run as java InstallCert github.com
and when it asks to enter cert number you need to enter 1
It will create a file with name "jssecacerts" in the current directory
1.c) But this program will not work because it does not know about how to authenticate with proxy. For this you need the code from SSLSocketClientWithTunneling page
Use the above two and create a program that tunnels through the proxy retrieves the ssl key and writes a file called jssecerts
2) Update your grails.bat with addtional options. Add these options to the %JAVA_EXE% command line. Paste them after %DEFAULT_JVM_OPTS%
-Dhttp.proxyHost=YourproxyURL -Dhttp.proxyPort=YourproxyPort -Dhttps.proxyHost=YourproxyURL -Dhttps.proxyPort=YourproxyPort -Dhttp.proxyUser=YourProxyUserID -Dhttp.proxyPassword=YourProxyPassword -Dhttps.proxyUser=YourProxyUserID -Dhttps.proxyPassword=YourProxyPassword -Djavax.net.ssl.trustStore=path-to-your-jssecacerts-created-in-step-1