I have installed and configured RavenDB in one of the server environment. (Windows 2012) I need to secure the Ravendb Studio, hence created self-signed certificate and applied the changed in the settings.json as given below
{
"ServerUrl": "https://11.135.25.16:12345",
"Setup.Mode": "None",
"Security.UnsecuredAccessAllowed":"PrivateNetwork",
"License.Eula.Accepted": true,
"Security.Certificate": {
"Path": "cloud16_company_com.pfx",
"Password": "123456789"
},
}
Once RavenDB starts it seems good and it is running on the given URL. But when I browse using Internet Explorer or chrome, it says "Authentication Error occurred".
Thanks
The issue is that you didn't register a client certificate to use for authentication.
You can register cloud16_company_com.pfx as the client certificate, which will work because RavenDB trust its own certificate. Or you can register an explicit client certificate.
That is probably a better idea. See here how to register / generate your client certificate:
https://ravendb.net/docs/article-page/4.1/csharp/server/security/authentication/client-certificate-usage
The following is taken from: RavenDB Documentation
Try closing all instances of the browser and then restart it.
If that doesn't work, register the client certificate in the OS store.
In Windows, double-click the certificate file and click 'next' all the way.
Related
Firefox 91.12.0
Windows 10 Enterprise for Virtual Desktops version 21H2 build 19044.1766
Visual Studio 2022 V 17.1.6
C#
.NET Core 6.0
System.Security,Cryptography.OpenSsl 5.0.0 nuget package
I am creating a certificate authority to programmatically generate client certificates. The CA (and the intermediate CA) is imported into windows. I have created an website in IIS that uses that certificate, and it works fine with all three browsers (edge, chrome, firefox).
I created another website in IIS to require client certificates, and I used my CA application to generate a client certificate. I imported that certificate using chrome, and I see that cert in MMC "Certificates - Current User" under Personal->Certificates. Both Chrome and Edge prompt for the certificate, and when I select it, it grants me access to the site, and I can see the index.html content.
Firefox does not prompt me for the certificate. In Firefox advanced preferences:
security.osclientcerts.autoload = true
security.enterprise_roots.enabled = true
I have tried to import the PFX file my app generates, within Firefox, and it prompts me for a password, but it issues the error message "The PKCS #12 operation failed for unknown reasons" ... which tells me precisely nothing.
In my research I have seen comments about certificate fields being encoded with "printable
strings" rather than UTF8, but I can find no way to control this, or even control it in anyway.
So what am I doing wrong? What special thing is it that Firefox needs that it isn't getting?
Edit: The issue I mentioned before, here, was that the cert did not contain PrintableStrings. I confirmed using ASN.1 Decoder that my cert does in fact use PrintableStrings for everything in the cert.
The problem was that when I generated the certificate it had the same serial number as the certificate from the CA. I changed the number to 9, and restarted Firefox, and it prompted me for the cert.
So ... apparently duplicate serial numbers among certs from the same CA are a problem for Firefox.
We're struggling to get IBM MQ to work across SSL.
We've been provided with the certificate chain for the remote host and installed into the Windows Certificate Store (Local Machine). These all look valid.
We're using the following connection properties:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "other-server.com");
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256"); connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*SYSTEM");
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmywindowsusernamewithoutdomain");
MQEnvironment.SSLCertRevocationCheck = true;
We've established that the "CertificateLabel" is the "Friendly name" in Windows parlance.
We've proven unencrypted communication and network-level configuration.
We're using 8.0.0.7 client.
These are the issues we've come across:
All secure communications fail with a 2538 error. (MQRC_HOST_NOT_AVAILABLE, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q045380_.htm)
No success setting the Friendly Name to ibmwebspheremq and ibmwebspheremqmywindowsusername#domain and ibmwebspheremqmywindowsusernamewithoutdomain
General questions:
Are we correct in assuming that we can install generated certificates exclusively in the Windows Certificate Store?
Is the 2538 error even related to SSL communications? It feels like a network error, though there is that final point in the referenced error documentation.
Is there anywhere we can look for more informative error information? eg. relating to the SSL trust chain to see if there is an issue there?
The issue was the following line:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "otherserver.com");
Turns out that:
It needs it in a canonical format, so DN=, etc.
You don't even need that line
Though we did learn a few things along the way:
The line:
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmyusername");
Is the string ibmwebspheremq plus your Windows username (without your domain) and the label should be set on the Friendly name of your client machine's outgoing certificate NOT including the username.
The various folders inside your Windows certificate store are significant. The intermediate CAs should be correctly filed.
I've genrated my application with JHipster. I've changed the authentication way in my project to use LDAPS.
I added configuration in application.yml
Server SSL:
key-store: classpath:keystore.jks
key-store-password: secret
key-password: secret
I didn't add any other code (i.e. java) for this certificate.
When I try to launch my application in a browser, it doesn't work; however if I delete this configuration, it works. Does my application really needs a certificate for the connection to LDAPS?
What is wrong with this code, should I add java code somewhere to complete my configuration?
Thanks for your answers
Not enough information to help you. Which version of JHipster, which authentication did you choose when generating your app?
To make it work with LDAP you must change the SecurityConfiguration class.
Worklight 6.0.0, targeting iPad.
I have a simple demonstration application, no authentication at present. I am demonstrating use of reverse proxy. So I am building my application using the Build for Remote Server workaround and can see in xcode the correct server specification. I have some adapter calls, but for a particular demo scenario I also want to make an explicit call to
WL.Client.connect( ... );
If I use an http connection I see a request like this:
http://192.168.0.19/MyApp/apps/services/api/Work01/ipad/init
and it works just fine. If instead I use an SSL connection, as expected I see this
https://192.168.0.19:443/Infrabel01/apps/services/api/Work01/ipad/init
And I get the following error.
> [ERROR ] FWLSE0059E: Login into realm 'NullLoginModule' failed. The
> environment 'ipad' supports multiple versions, therefore you must
> request it with a version parameter.. [project Infrabel01] The
> environment 'ipad' supports multiple versions, therefore you must
> request it with a version parameter. [ERROR ]
> FWLSE0117E: Error code: 4, error description: AUTHENTICATION_ERROR,
> error message: An Error occurred while performing authentication using loginModule
> NullLoginModule, User Identity Not available. [project Infrabel01]
> [project Infrabel01]
That "request it with a version parameter" is intriguing. Is there some extra parameter I need to pass? Or is the overall implication that connecting over SSL requires authentication?
I had the same problem.
I have solved it by using the real IP address of the server in the WL app instead of using localhost:
When the emulator is running your app, press the Menu button.
Select to change your server URL
Remove "localhost" and use the IP address.
Accept and try again.
This fixed my problem.
Please make sure your Worklight server or proxy server is enabled SSL with certificate which signed by a trust public CA like Verisign. Worklight not support private CA certificate.
We have an application that auto-generates a certificate and binds it, using httpapi, to a selected port. Under Windows 7, and 2003/2008 Servers this works like a charm. The certificate can also be rebound to other ports by un-binding, then binding to the new port.
Under Windows 8, however, only unbinding from the old port succeeds. An attempt to bind the certificate to the new port value fails with error code 1312 revealing the message "A specified logon session does not exist. It may already have been terminated."
What's odd here is that when trying to add a bound certificate through netsh it also fails, in elevated console, with the same error and message ("SSL Certificate add failed, Error: 1312|A specified logon session does not exist. It may already have been terminated."), regardless to the port number.
To add suspense, the application has an installer that initially binds the certificate on install, and unbinds it on uninstall. And this thing never fails! The installer works in "Windows 7" operating system context, while the application is under "Windows Vista", if this can be a clue. The console is under "Windows 8" context.
Has anyone had a similar problem under this OS? Any ideas why this might be happening?
Any help is highly appreciated, thank you in advance!
In our certificate generating code, we used X509Store class' methods to add the certificate to the store. Under Windows 8 this rendered the certificate "untrusted" even if the application was run as administrator. The cause might be either different implementation of the class in .NET 4.5 or imposed limitations due to the OS context the application was running in.
Solved the problem by invoking "certutil.exe" through a Process class to add the certificate to the store.