We are developing a local server app (written in nodejs for now), used by our web site to manipulate local files and folders (browse, upload, download...).
Basically, the customer installs the nodejs app, which starts a local server listening on 127.0.0.1.
Then, when (for instance) a list of local folders is needed on the web site, a JS script queries the local server, which returns the local folders, and they are displayed on the web site.
The problem is when the web site is configured in HTTPS, the web site's JS refuses to communicate with the HTTP-non-S nodejs app.
We are exploring various options :
using self-signed certificates deployed with the app, and trusting them on the machine during install, but I feel there will be a LOT of times when it won't work
using "proper" certificates for local.example.com, with a DNS entry where local.example.com points to 127.0.0.1, but it seems that distributing private keys to the general public is prohibited by the CGU of most (if not all) certificate authorities.
Now I thought of maybe another mean. Can a "packaged" HTTPS server (written in any language, I don't care), "living" inside an exe file, which is signed with a proper SSL certificate, use the certificate of the app?
I'm not sure if I'm making any sense, I don't know certificates very well...
Thanks!
We ended up adding a self-signed root CA using certutil :
certutil.exe -user -addstore Root "mycert\rootca.cer"
Since we're adding a root CA, it generates a warning popup that the user has to accept, but it has been deemed acceptable by the powers that be.
There is a "check config" screen that can try to add the certificate again if it hasn't been properly added the first time.
There is a case when the group policies (GPO) prevent trusting self-signed certificates. In this case, certutil has a return code of 0 (the certificate is added) but the root CA is not trusted, so the local server does not work. So, after install, we have to check that the certificate is trusted using:
certutil.exe -user -verifystore Root xxx
(xxx being the certificate serial number). This command does exit with error if the certificate is untrusted either, so we parse the output for CERT_TRUST_IS_UNTRUSTED_ROOT or 0x800b0109.
Related
I am new to the SSL stuff, and developing WebApi .net core 3.0 that will be consumed by react (both hosted on same webserver-IIS 10 on 443 port).
Can you tell be very clear and detailed steps to make it work
The DNS mapping is done and WebApi and react app both are hosted on IIS, but when API is being called from react it is giving error ERR_CERT_AUTHORITY_INVALID
Dev and Test server will not have an actual certificate, so what settings I should do (how should I
generate cert and add on IIS?)
I've followed some blogs/videos but, I am missing or doing something wrong.
If you want to create a self-signed certificate in iis you can try one the below way:
1)using GUI
open iis manager
Click on the server name in the Connections column on the left and Double-click on Server Certificates
Click on Create Self-Signed Certificate in the Actions Column on the right.
Type any meaningful name and then click OK to proceed
Click OK. Once that is complete you should now see the SSL in the list of Self-Signed certificates.
2)using command prompt
New-SelfSignedCertificate -DnsName www.domain.com -CertStoreLocation cert:Localmachine\My
You could also try to move the certificate to the trusted root by following below steps:
1)open mmc.exe as administrator.
2)In the MMC Console, in the top menu, click File > Add/Remove Snap-in….
3)In the Add or Remove Snap-ins windows, in the Available snap-ins: section, select Certificates and then click Add >.
4)In the Certificate snap-in window, select Computer account and then click Next.
5)In the Add or Remove Snap-ins window, you should now see the Certificates (Local Computer) snap-in.
6)Click OK
7)In the MMC Console, in the console tree, expand Certificates (Local Computer) > Personal, and select the Certificates folder.
8)In the center pane, select the certificate that you want to move.
9)Right-click on the certificate and click Copy.
10)now Expand Trust Root Certification Authorities, certificate folder.
11)right-click on the middle pane and paste certificate.
If you have a certificate already then you can import and set it at the trusted root store by following below article:
How to trust the IIS Express Self-Signed Certificate
I'm trying to make a Progresive Web App, with wamp server, but I need an environment that closely mimic production environment. So I'm using a virtual host to mimic a real domain, and using a self signed certificates to use an HTTPS.
The Problem is self signed certificates is not trusted by the browser, and makes my Service worker failed to register.
I've tried the solution from this thread Can you use a service worker with a self-signed certificate?, by creating a new shortcut on my desktop with the targets
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://myvirtualhostname.com
But that doesn't solve the problem. Please anybody could help on this matter??
You should not need the --unsafely-treat-insecure-origin-as-secure flag, since that applies to insecure HTTP origins.
The --ignore-certificate-errors flag will give a warning on Chrome, but you can ignore this, it will work.
I am working on a project using libtorrent for some clients and a open tracker using mono torrent.
Pc1: Runs a tracker using mono torrent, which hosts the .torrent
Pc2: Runs a lib torrent client and hosts the content referenced in the torrent and has the .torrent, which is added to the client by passing a signed certificate, a matching private key, and dhparams and the password for the signed certificate.
Pc3: the same as Pc2 but does not host any content referenced by the torrent
The torrent is created with a CA certificate and a private key matching the CA which the signed certificates is signed against, using openssl. With no errors. (This is done on a seperate Pc from the other 3).
When I run the tracker I get no errors, only that it's running and tracking the torrent.
When I run the clients it gives me a torrent need cert alert, and I then set_ssl_certificate on the handle for the torrent, and then resumes, and I get a torrent_error_alert telling me that the torrent doesn't exist, and finaly it changes state to checking and then seeding/downloading depending on which client it is (the uploader or downloader).
The problem is then, that there is no traffic between the clients.
I can see that they are connected to the tracker, and are listening on both normal ports and the ssl ports, but there is never a connection between the two clients (Using TcpView).
There is no difference when I run with or without admin rights.
Anyone who has experienced this, or might have a solution/pointer in the right direction?
Many thanks in advance.
My old Live system (Domino 8.5.3 / Windows 2003) is out on the DMZ and needs to be upgraded to a SHA-2 certificate. So, we have built a new Test server also out in the DMZ (Domino 9.0.1 FP6 / Windows 2008) box to move the site to.
I copied the entire Data directory from the Live over the top of the Test 9.0.1 folder to bring across all the databases and jQuery files etc...
I then followed this procedure to create the new certificate:
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/3rd_Party_SHA-2_with_OpenSSL_and_kyrtool?open
I used the procedure to generate a new CSR which we sent to GoDaddy to have them reKey the SHA-2 for the new Test system.
They returned to CRT files.
1) gd_bundle-g2-g1.crt - This I believe holds the Root and Intermediate certificates. But, I only found two certificates in this.
2) 8e0702e83bd035e9.crt - This has the Site certificate
I extracted the two GoDaddy certificates:
godaddy_root_Base64_x509.cer
GoDaddy_Secure_CA-G2_Base64_X509.cer
Then used the following command to join them all together:
type server.key 8e0702e83bd035e9.crt GoDaddy_Secure_CA-G2_Base64_X509.cer godaddy_root_Base64_x509.cer > hbcln04_server.txt
I followed all the steps in the procedure above. The only difference is that the proceedure shows 2 intermediate certificates but GoDaddy only sent me one.
But, I was able to verify both the Keys and the Certificates as the procedure said.
There were no errors in the process.
I put the new kyr file down in the Data directory with the others and then went to the Website document and changed the reference there to the new kyr filename.
Note, this is a Website document not the Server document.
I even went to the Server document and followed a procedure to Disable and Enable the Website documents just in case the path to the Keyring.kyr file was corrupted.
However, because the new Test box is in the DMZ it is very difficult to test.
So, I have modified the servers Host file to map the certificates domain back to the same box. (Otherwise the DNS would keep taking it back to the Live system.)
There is a question as to whether mapping the domain to the IP of the Test box will work with HTTPS. But, I don't see why not.
But no matter what I do, I can't get the certificate to take hold.
I put in the URL for the site and if it is HTTP it works, But soon as I change it the HTTPS I get this:
This page can’t be displayed
List item Make sure the web address https:_Link_to_site is correct.
List item Look for the page with your search engine.
List item Refresh the page in a few minutes.
I then refresh the page and I get this:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https:_Link_to_site again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
Well unfortunately, I'm the site administrator!
The only things I have seen differ to the procedure is:
1) that I only had 1 intermediate cert and not 2 as in the example.
2) I'm using a Host file to map the domain to the server so it doesn't follow it's usual DNS.
Also note that there are no errors in the log. We did have a few around the Access to the Key files. The kyr file was fine, but the sth file had restricted access. This has been corrected now.
At the moment, I don't know where to even look for an error or what to turn on to see the error.
It seems the certificate just doesn't load.
Please help.
I have a .NET application built with Mono, that I've bundled into a native (Linux) executable using mkbundle. This is so that end users don't need to mess around and install Mono themselves.
The application uses ServiceStack, which under the hood uses HttpListener. I need the web services to be exposed over an SSL-enabled HTTP endpoint.
Normally, you would run something like httpcfg -add -port 1234 -p12 MyCert.pfx -pwd "MyPass" during configuration (all this really does is copy the certificate to a specific path), and HttpListener would automatically bind the certificate to the port.
So HttpListener loads certificates from a particular path at runtime.
Is that path hard-coded? Or is there some way I can tell it to use a certificate from another location, since the end user will not have Mono installed?
Yes the path that HttpListener expects to find certificates at is predefined, and cannot be specified by the user, programatically or through a config file. The Mono EndPointListener class will look for the path:
~/.config/.mono/httplistener/
HttpListener code:
string dirname = Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData);
string path = Path.Combine (dirname, ".mono");
path = Path.Combine (path, "httplistener");
As you have noted this is the same path the httpcfg copies certificates to.
Even though you are using mkbundle, this is still where HttpListener will expect to read the certificate from, regardless of the fact that the Mono runtime is installed.
In your application startup, you should:
Check for the existence of the directories, and create as required
Write your certificate and key to that path from an embedded resource in your application. PouPou's answer here shows the method used by HttpCfg.exe.
Therefore eliminating the requirement to run httpcfg, you will effectively be building that functionality straight into your application.
Does Mono perform any validation of the certificates it loads from there for HttpListener? i.e., will it expect to find the issuer's certificate in the certificate store?
I don't know for sure if Mono checks for a valid corresponding issuers certificate in the certificate store at the point of creating the listener, or upon each connection request. However you can add a CA cert to the certificate store yourself, or import all the standard Mozroot certificates.
The full source code for Mozroots is here. This shows how to import the CA certs.
Is the path to the certificate store also hard-coded?
The certificate store should be managed through the X509StoreManager provider.