I am trying to set up a neo4j server with a set of certificates for https. I have the key used to get the certs, the certificate itself, and the ca certificate chain file. According to the documentation:
Neo4j also supports chained SSL certificates. This requires to have all certificates in PEM format combined in one file and the private key needs to be in DER format.
I've encoded my key in DER format and have that set up, however I am having trouble getting the certificate chain set up correctly. I combined all the certificates in one file (PEM) and gave it to neo4j, and it crashed silently trying to start the server. On the off hand, I took the first certificate and changed it to DER, changed neo4j to use that, and it started but browsers/curl throw a fit because there's no CA chain along with it.
This is using neo4j 2.2.0 community edition.
Any suggestions as to how to get neo4j to use PEM certificate chains correctly?
See https://github.com/neo4j/neo4j/tree/2.2/community/server/src/test/resources/certificates for certifcates used when running the unit tests of Neo4j. Most interesting test case is https://github.com/neo4j/neo4j/blob/2.2/community/server/src/test/java/org/neo4j/server/security/ssl/KeyStoreFactoryTest.java#L82
Double check if your pem file has the same structure than the one provided there.
Related
I'm developing some code to connect my Beckhoff controller to microsoft Azure through MQTT Iot. To start I have used the example code provided by Beckhoff. Azure side is configured and I have the SAS Token. In Twincat I pasted the code and configured everything except the TLS/certification configuration since Beckhoff documentation it's a bit confusing at this point
https://infosys.beckhoff.com/content/1033/tf6701_tc3_iot_communication_mqtt/3528172299.html?id=376207444360410914
(¿CA is optional but mandatory at the same time?)
Anyway I tried to get a CA certificate to test. As I don't how/where to get it, I tried to export Baltimore certificate to a file with certmgr.exe but the format it is not .crt type as in documentation example. Export formats are cert and p7b type. If I try with any of these types of files I get a TLS validating error in connection.
I'm a bit lost at this moment so any steps to help me in this part?
I'm not familiar with certification/TLS so can you please guys provide some tips or info links focused in this matter so I can get this kind of certificates to validate the connection?
Thanks in advance.
The CA location is optional, since it will be searched for at its default location. Nevertheless, the CA file has to be at the specified location or at the default location. The CA file has to be saved with PEM formatting, but it doesn't matter which extension the file has.
The connection configuration regarding the SAS-token is different whether you connect to an azure-device or -module.
To connect to an azure-device, the following has to be configured:
sUserName := ''; and sUserPassword := '';
copy-paste the SAS-token from e.g. Azure Iot Explorer into stTLS.sAzureSas (the SAS-token is formatted like this: HostName=<hub-name>.azure-devices.net;DeviceId=<device-id>;SharedAccessSignature=SharedAccessSignature sr=<hub-name>.azure-devices.net%2Fdevices%2F<device-id>&sig=...&se=...)
To connect to an azure-module, the following has to be configured (like in python):
sUserName := '<hub-name>.azure-devices.net/<device>/<module>/?api-version=2018-06-30';
sUserPassword := 'SharedAccessSignature sr=<hub-name>.azure-devices.net%2Fdevices%2F<device-id>&sig=...&se=...'; (this is part of the SAS-token, copy everything after ...SharedAccessSignature=)
stTLS.sAzureSas := '';
Publishing messages, take care to send to only send to the expected topic, otherwise the message won't be sent and the connection temporarily lost.
(¿CA is optional but mandatory at the same time?)
Because you must connect over TLS/SSL, you will need to reference the DigiCert Baltimore Root Certificate to connect to Azure IoT Hub.
You can find this certificate in the Azure-iot-sdk-c repository
My recommendation is that you follow steps described in the documentation on how to Communicate with your IoT hub using the MQTT protocol
I am studying the SSLCustomIOHandler Intraweb example to figure out to make the intraweb standalone webserver work in https.
The example uses 3 .pem files:
basically the code that uses the files is
{ TIWIOHandlerClass }
procedure TIWIOHandlerClass.Init;
var
Path: string;
begin
Path := TIWAppInfo.GetAppPath;
with SSLOptions do begin
CipherList := 'AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!MD5:!aNULL:!EDH';
SSLVersions := [sslvSSLv2, sslvSSLv23, sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2];
CertFile := Path + 'cert.pem';
KeyFile := Path + 'key.pem';
RootCertFile := Path + 'root.pem';
OnGetPassword := DoGetPassoword;
end;
inherited;
end;
Now i don't find documentation on this thing. This Indy documentation page says something about certfile and keyfile.
But Rootcertfile and cipherlist are not clear.
Do you have some knowledge to share about this? Basically I'd like to have a https webserver with valid certificate ("green https" in chrome).
Thanks.
This question has a lot to to with with SSL and public key infrastructure (PKI). You can find a lot of information on that topic on the web, but I'll try to help you get started. I don't have a version of Intraweb that supports SSL so I could not compile the sample, but hopefully this will get you somewhere.
In order to get "green https" in Chrome a few things must be fulfilled. In simple terms, this means that the certificate presented by the server must be valid in terms of expiry date, it must have a supported crypto algorithm, the hostname must be the same hostname as the requester, or client, used etc. This is far from a complete list, but you get the idea. In addition to this, the client must trust the certificate, either directly or through a hierarchy (hence the "infrastructure" in PKI). Browsers and operating systems come preloaded with authorative certificate issuers that we are assumed to trust, often called CA's (Certificate Authority). Since it is a hierarchy, there can be a path between who issued your certificate and who your browser trusts. For this reason, many clients need the server to provide a "certificate chain", that shows the path all the way to the highest CA. This is what the Rootcertfile is for.
If you want a server that is trusted for normal internet users, you need to get a certificate from a trusted authority. You can get simple free certificates from sites like "Let's Encrypt", but there are a few prerequisities that has to be fulfilled (for example having administrative authority of a domain), and there is also things like certificate renewal that need to be handled.
An easy way to get started is to create a self-signed certificate. This will give you the cert.pem and the key.pem. Since the certificate is "self-signed", you are your own root, so if you must have a root.pem I think you can use the cert.pem there as well. You don't have a hierarchy, and your certificate will not be trusted by anyone until you convince them otherwise.
I think that the cipherlist has to do with which ciphers the server supports. You can probably use the default as a start.
In order to make Chrome happy you need to import the self-signed certificate into the Trusted CA store on your client. You also need to make sure you can resolve the name(s) in the certificate. The easiest way is to add the name to the clients hostfile. This does not have to be the computers actual hostname, you can use.whatever.you.want.
This is a good thread regarding self-signed certificates. Since you want to get started quickly, I'll cover the basics here. I guess you are on Windows since you are running Delphi.
Download and install OpenSSL. I used
Win64OpenSSL_Light-1_1_0g.exe from Shining Light
Productions.
Create a text file called req.cnf with the contents below. This file
is required because modern browsers requires that the hostname is
present in the SAN field.
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = NA
ST = NA
L = lab
O = lab
OU = lab
CN = www.myintrawebserver.local <--- Replace with your name
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = www.myintrawebserver.local <--- Replace with your name
DNS.2 = myintrawebserver.local <--- Optional additional name(s)
Go to a DOS prompt and run the following command (The backslash
after "365" is just to make this easier to read, it won't work on
Windows):
C:\home>\OpenSSL-Win64\bin\openssl req -x509 -sha256 -nodes -days 365 \
-newkey rsa:4096 -keyout key.pem -out cert.pem -config req.cnf
If everything work you'll get the files cert.pem and key.pem written in
the current directory.
Generating a 4096 bit RSA private key
.......................................................................
...................................++
.......................................................................
.......................................................................
.......................................................................
......................................................++
writing new private key to 'key.pem'
-----
Add the hostname into the C:\Windows\System32\drivers\etc\hosts file on the client computer. Remember that you need to edit the file as Administrator.
Import the cert.pem into the truststore. This can be done via settings->advanced->certificates (or something like that). Add the certificate to the Trusted Root Authorities (I don't know the exact name, my computer has a non-english language).
Run and access your application. Hopefully your browser is happy :-)
The key.pem is not password protected in this example. I don't know if the
OnGetPassword has something to do the key password or if it is a password
that the user is expected to provide.
SSLSHopper has some useful tools to check certificates. Try for example to paste the content of the cert.pem in the Certificate Decoder. Sample output below.
The certificate is divided in two parts, so to speak. The cert.pem is the public part, and the key.pem is the part that needs to be kept secret. The public part needs to be decoded by clients in order to determine if they can trust it or not.
How2SSL also has some good information on SSL. Here can you read more about PEM-files specifically. PEM is just one of the many file formats that help complicate the world of PKI ;-)
I am having difficulty making connection to secured webservice. My service provider gave me a WSDL URL (which uses SSL Connection) and a PFX file. The service provider told us that WSDL can only be accessed by users belonging to our network.
So far I have tried:
(i) Exported key from given pfx file to separate keystore
(ii) Exported certificate to (a) java 's default truststore (b) seaparate store
I have set system properties:
System.setProperty("javax.net.ssl.keyStore", "C:/Test/keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "test123");
System.setProperty("javax.net.ssl.keyStoreType", "jks");
System.setProperty("javax.net.ssl.trustStore", "C:/Program Files/Java/jdk1.7.0_17/jre/lib/security/cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
I am using latest versions of CXF & Java. I got several exceptions which I could resolve by Googling the issues, but I am finally struck with "could not send message exception". How can I deal with this exception?
We are using ClientCertificate authentication with HttpWebRequest. For the client certificate authentication we are creating the X509Certificate from Pfx file and attached to the outgoing HttpWebRequest.
What we see is that after the request is created we are seeing to many temporary files in the folder : C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
As we make more request we see that the number of temporary files created in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder is increasing continuously.
We create the certificate from pfx file and then we set the key container. Expilicity access is granted using CryptoKeySecurity and CryptKeyAccessRule. The private method SetKeyContainerSecurity takes the CspKeyContainerInfo and CryptoSecurity. Then it uses the CryptAcquirecontext and CryptSetProvParam to set the key container security.
The issue we are facing is large number of temporary files getting created in the disk at location : C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
What is the correct approach to ensure that these temporary files are deleted.
Is the hotfix at http://support.microsoft.com/kb/931908 relevant? It addresses the issue "On a Windows Server 2003-based or Windows Server 2008-based client computer, the system does not delete a temporary file that is created when an application calls the "CryptQueryObject" function"
I am trying to do a simple
OpenSSL::X509::Certificate.new(File.read("testuser.p12"))
from irb with ruby 1.8.7 (or 1.9.2), same result for both. The error I get back is OpenSSL::X509::CertificateError: nested asn1 error
Is this a ruby issue, or does this suggest the cert itself is malformed? I've found some similar reports revolving around an amazon cert demonstrating such errors, which turned out to be the cert itself. It works in the browser though. Suggestions on how to resolve this?
"testuser.p12" seems to be a PKCS#12 file according to the postfix. Reading PKCS#12 format as X.509 certificate format causes ASN.1 decoding error.
You should do OpenSSL::PKCS12.new(File.read("testuser.p12")) instead. If the file is protected with passphrase (it's normal), give the passphrase as the second parameter for PKCS12.new like OpenSSL::PKCS12.new(File.read("testuser.p12"), "pass")
You can extract certificate and CA certificates by PKCS12#certificate and PKCS12#ca_certs methods.
p12 = OpenSSL::PKCS12.new(File.read("testuser.p12"), "pass")
p p12.certificate
p p12.ca_certs