I generated a self-signed SSL certificate for a local server test and I have some problems for using it. My aim is to test it with a websocket secured (wss) server.
The browsers are refusing the connection saying that the pair certificate has an invalid signature. Firefox return this error code: sec_error_bad_signature.
I generated the certificates and keys with the method described here (in french but you can only look at the openssl commands): http://www.siteduzero.com/informatique/tutoriels/securisation-d-un-chat-reseau-qt-avec-qsslsocket/ou-trouver-les-cles
Do you know how I can resolve this problem?
I believe the problem is caused by the 512 bit key size in your certificates. Microsoft released a security patch (KB2661254) that blocks RSA key lengths less than 1024 bits.
Try creating your certificates with a 1024 bit or higher key length and see if the problem goes away.
Related
I'm fairly new to the whole certificate shebang and not a versed Linux admin.
In our company, we run a Windows domain, but we also have some CentOS servers for different services.
On one of said servers we have our ticket system, which is browser based. I want to certify it with a certificate, signed by our Windows root CA, but no matter what I do, the certificate is shown as invalid in the browser.
Funny enough, both certificates in the chain (CA -> server) are shown as valid.
I already did the following:
start certificate process from scratch
tried different certificate formats (.cer, .pem)
verified server cert with root cert
checked validity with openssl (OK)
checked SSL connection with openssl, no issues
added root cert to Linux server trusted CA store
recreated cert chain (of 2)
restarted Apache over and over
reset browser cache
tried different browser
checked DNS entries
checked, if root CA is trusted in Windows (it is)
manually installed server cert in my browser
Both the server cert and the root cert show up as valid in the browser, with the correct relation.
I'm completely lost here. Is there some key step I forgot and not one of the ~30 guides I read forgot to mention?
Any help is greatly appreciated
Your question is missing some information:
Did you check the SSL connection from outside the server?
Did you verify the RootCA cert is inside the cert-store of the server (sometimes it is rejected without error messages)?
I would check the reason for rejecting the certificate in the browser (FireFox is usually more informative than Chrome), and look for the error-code.
Reasons can be (some of which you have already verified):
Wrong certificate properties (missing the required values in the "usage" attribute)
Wrong domain name
Expired certificate
Certificate could not be verified on the client-side
See this image as an example of an error code:
https://user-images.githubusercontent.com/165314/71407838-14f55a00-2634-11ea-8a30-c119d2eb1eb1.png
I deploy my CA cert via GPO into Trusted Root Certification Authorities, which I can see is deployed to my client machines. I know this part is working as Chrome no longer moans when browsing to sites using my signed SSL certs.
However, when I try and git clone or push to any repositories behind an SSL cert signed by this CA, git-for-windows bawlks and says this:
schannel: next InitializeSecurityContext failed: Unknown error
(0x80092012) - The revocation function was unable to check revocation
for the certificate.
As you can see, I've got schannel enabled, but git-for-windows is clearly not reading my CA cert from the Certificate Store in Windows. Any one know how I make gfw read from the Certificate Store in Windows? I can't manually copy this cert onto all my Windows clients, that'd take forever.
Perhaps worth noting I'm using multiple Samba 4 instances as Domain Controllers, but I don't have access to Windows Server tools such as AS Certificate Services.
nb. I know I can disable tls verification, but that surely defeats the purpose.
I have made my cert and key using the following
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
And configured it in my Golang code
log.Fatal(http.ListenAndServeTLS(":4201", "cert.pem", "key.pem", router))
It worked well when accessing using chrome but it throws the error on the console when accessing using firefox.
2018/03/02 16:54:11 http: TLS handshake error from 100.67.56.121:54397: remote error: tls: unknown certificate authority
How can I solve the issue?
"Remote error" means error sent from client (firefox in this case).
Solution is to figure out why firefox doesn't like the certificate and fix it.
There is something that firefox doesn't like about the certificate. Open up firefox dev tools and see if you can find any warnings regarding the certificate. If you had to manually accept the certificate in Firefox then it is possible that Firefox is still reporting to the server that it doesn't like the certificate even though you have told firefox to load the page anyway (see chrome example below).
However as this is a self generated/signed certificate the warning is probably because firefox doesn't trust this certificate. Solution is to either add this certificate to firefox's trusted certificates if this server is only for your own personal use...or to get a certificate signed by a commercial CA or letsencrypt.
"Fixing this server-side" means fixing whatever it is about how your certificate/app is served in order to make it trusted by firefox. Or I suppose ignoring the errors if you are just doing development.
More details...
Key thing here is that this is a "remote error" meaning it is an error from the tls CLIENT connecting to your server. In your case it is Firefox complaining during the TLS handshake that the certificate is invalid in some way.
I noticed the same thing with chrome. Cert is signed by a public CA (ie a CA that should be trusted by most browsers) but as I am developing on my local machine, the certificate is invalid because hostname (localhost) doesn't match the certificate CommonName (CN) or Subject Alternative Names (SAN).
Easiest thing to do is just look at the TLS handshake in wireshark.
I told chrome to accept the certificate, started capture and did a SINGLE refresh of the page (https://localhost:8081 in this case). Chrome does not present me with a warning page and shows the content. There is a red warning in the address bar however.
The interesting thing (to me) is that it appears (I'm no TLS expert) that there are two TLS handshakes.
Client Hello
Server Hello
Alert (client error)
Client Hello
Server Hello
Client complete handshake
...encrypted application data...
Since chrome doesn't interrupt my refresh of the page I am not sure why chrome does the handshake twice (first time with Alert/failure) for a single page refresh.
The interesting bit I learned here (obvious in hindsight) is that it is possible to get reporting from browsers/clients when they reject your certificate. This can be used on the server side (if monitored) to discover subtle certificate mis-configurations in production that your test cases might not cover. Unfortunately as this is pre-http you won't get user-agent or anything useful to help with reproducing....but a large number of these errors as a percentage of server traffic indicates you need to do some serious cross browser/os/device testing
API GET call from a website only from mozilla browser I get following error "VIP uses invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported”
tested the vip thru SLLLABS.com found out that cipher suite returned from my certificate from server is not in the preference list of mozilla - https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=47&platform=Win%207&key=132
Is this could be the issue ? How to add the required cipher suite in the certificate, what steps to follow.
Report also indicated there is no forward secrecy and session cahcing, not sure if this causes this issue?!
SSL Lab report.
Firefox 31.3.0 ESR / Win 7 Server closed connection
Firefox 46 / Win 7 R Server closed connection
Firefox 47 / Win 7 R Server closed connection
Forward Secrecy No WEAK (more info)
Session resumption (caching) No (IDs assigned but not accepted)
cipher suite returned from my certificate from server is not in the preference list of mozilla - Is this could be the issue ?
No. Your error message is specifically:
"The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported"
This specific issue is that Firefox can't build a chain back to a trusted root. Firefox uses its own root store and root program, so it differs in behavior of IE / Edge / Chrome, all of which use the Windows certificate store or OS X certificate store.
Without knowing exactly which CA issued your certificate, and what intermediates your server is set to serve, it's hard to say exactly what is wrong.
If SSL Labs says the certificate is fine, look for "incomplete chain" or "extra downloads" in orange where it displays the certificate chain. If those show, then you have an incomplete chain, which are necessary to building back to the root.
If SSL labs says your certificate isn't trusted (shows a big red 'T') then your certificate is not issued by a public CA, or SSL Labs wasn't able to find the intermediates, either.
Report also indicated there is no forward secrecy and session cahcing, not sure if this causes this issue?!
Forward secrecy is a very good thing to have enabled but it is not the cause of this error.
I am trying to make websocket connection to a backend server that uses a self-signed certificate. In firefox I've added an exception for the self-signed cert.
However my websocket connection wss:// fails to connect. I get a close event with code 1006 which is a catch all code.
Chrome and IE websockets work. Since I am using windows, I've installed the cert using certmgr.exe as a trusted cert.
My guess right now is that firefox websockets do not work with certificate exceptions and need to be trusted.
Has this scenario worked for anyone else?
Just in case it could help anyone, what is mentioned in OP's answer is not true at this time of writing (v61.0.1).
I navigated to the address of my WS server using https, as any WS server is practically an HTTP server, then the usual invalid certificate screen appeared and allowed me to add an exception. After that any wss connection made to the same host and port is successful.
Firefox works with secure websockets (wss://) only when the certificate of the site is trusted.
With a self-signed certificate I was able to browse the site by adding an exception to the certificate. The exception is not used for websockets and the connection was dropped during the ssl handshake.
Instead I created my own Root CA cert and then another signed cert for the webserver. In Options > View Certificates > Authorities I imported the Root cert. Now firefox is able to connect over secure websockets without any issue.
Firefox does not allow for importing of self-signed certs as Authorities. Windows Certificate manager allows importing of self signed certs into the "Trusted Root Certificate Authorities" list.