I made a tool that exposes a web-interface for the localhost. Now, i require this web-interface to register a https prefix for a page. For this i'm using BouncyCastle to generate a root certificate and a ssl certificate. This all works well (generating, signing and binding to port). IE displays the page by https without certificate warnings etc.
However, when a third party app tries to display the webpage, it fails (unable to load and displaying 'about:blank'). Because it is an embedded webbrowser i am not sure what the exact problem is. Thus, along other stuff, i tried to use fiddler to maybe determine the problem - only to find it DOES accept the certificate fiddler generates.
So what i have done is exporting the fiddler certificates and removed all custom certificates from the stores. Then, i imported the fiddler certificates on the exact same stores where my generated certificates are. I also made sure that the build up (all stuff you can inspect by viewing the certificate properties) are exactly the same. By using Windows MMC, clicking the certificates i can see NO difference, even the order is the same. Critical and such - all match. The only thing that is slightly different: the serial number from my certificates are shorter then the ones generated by fiddler.
So what i end up with are 4 certs (I deleted all the original from fiddler): 1 ssl and 1 root from fiddler and 1 ssl and 1 root from BouncyCastle. The roots are in trusted and the ssl in personal, both on localmachine. Now, when i use netsh to bind the fiddler cert to the port, it works. When i bind my own certificate to the port, it fails.
I have no idear why as all the properties look the same to me.
There is one thing though (again, i have no idea what is going wrong, so this might be irrelevant): on the SSL cert (so not the root one) the SKI points to nowhere (or, at least, i dont see where it points to), but this seems to be the case on the fiddler cert as well. Obviously for both certs the Authority key id point to their respective roots. The SKI on the SSL cert is set by
certificateGenerator.AddExtension(X509Extensions.SubjectKeyIdentifier, false, new SubjectKeyIdentifierStructure(subjectKeyPair.Public));
BTW, i use a VM for testing wich is reset everytime, so i don't think i messed up the cert store somewhere along the way. The tool stays the same, the only thing that changes is the bound certificate, both are registered to 'localhost'
IE thirdparty browser
fiddler's good good
Own's good fail (without message)
Why can 2 seemingly identical certs have a different impact? Is there anything i'm missing in hidden properties or something? And, if so, what should i look for?
Ahhhhhhhhhhhhhhh.... Minutes after this post i saw the flaw... It had not to do with the certificate at all, but the way it was bound to the port.... I used code from Mike Bouck to bind the certificate. This line was causing the problem...
configSslParam.DefaultFlags = (uint)NativeMethods.HTTP_SERVICE_CONFIG_SSL_FLAG.HTTP_SERVICE_CONFIG_SSL_FLAG_NEGOTIATE_CLIENT_CERT;
Changing the flags to 0 made it work....
Wasted hours.... :(
Related
I just setup MagicDNS and HTTPS on my tailscale account.
Then I ssh'ed into my nas and issued a tls certificate with
sudo tailscale cert "machinename.tailnetalias.ts.net"
Response was:
Wrote private key to machinename.tailnetalias.ts.net.crt
Wrote private key to machinename.tailnetalias.ts.net.key
Now when I try to access the web interface of my nas via https:// in a browser, I get an error. Firefox for example says "SSL_ERROR_RX_RECORD_TOO_LONG".
What can I do about this?
The tailscale cert command doesn't know where the certificate files should be installed (it doesn't even know what you were planning to do with them). So the first question is: did you move those files somewhere to install them? If not, the certificate getting SSL_ERROR_RX_RECORD_TOO_LONG is likely some other cert file which was already there.
If the tailscale cert files did get installed, I think the next step would be to click on the lock icon in Firefox on the left side of the URL. It will have a bunch of information about the TLS connection, in particular:
if the certificate had something wrong with it
in the Technical Details section, it will say what TLS version was used (SSL2, SSL3, TLS1.0, TLS1.1, TLS1.2, TLS1.3).
The SSL_ERROR_RX_RECORD_TOO_LONG error was mostly a problem in older versions of TLS like 1.1 and before. If the TLS version is one of those, it may be necessary to figure out how to get the NAS to stop offering the older versions and only offer 1.2 and 1.3.
I can't work out a definitive answer on this, but from searching I find two links which seem to indicate to me that a server (in this case it's MS Exchange as per the links) can have different certificates in place for https than for secure smtp/TLS.
http://technet.microsoft.com/en-GB/library/bb851505(v=exchg.80).aspx
https://www.sslshopper.com/article-how-to-use-ssl-certificates-with-exchange-2007.html
I have an issue which no-one has been able to help with here and this question is a follow on, in that I am coming to the suspicion that my first problem is that my machine trusts the https certificate, but not the one being used for smtp/TLS. But what I'm asking now, is that even possible?
Going through the diagnostic steps here shows me that the certificates in use when I access my mail server's web interface through https are fully trusted. However when I look at the debug of my c# process it is stating a completely different certificate issued by one of our servers to it's self (the server on which exchange is installed).
So... any one know if it's possible that I am thinking along the right lines... is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Yes, you can have a different certificate for each listening socket on the machine, that is SMTP and HTTPS can use different certificates. On a machine with multiple hostnames you could even have multiple different certificates on a single socket, which get distinguished by the hostname (using SNI).
I am trying to write a redirect in apache for URL of pattern:
https://server.com to https://www.server.com
without much success
Reason for rediect: My SSL certificate is on www.server.com, so I want the users to go on the correct site (and see secure icon).
Problem: The problem is that when I try to open https://server.com the browser gives me incorrect certificate error and none of my RewriteRule gets executed till I ignore the incorrect certificate problem.
How do I redirect in this case?
You can't do this with one certificate. The reason is that the web server needs to do the ssl handshake before it does the redirect, so you'll always have the problem with invalid certificate.
You really have only one option to do this - cover both, www and no www with a certificate and redirect. This can be done several ways, either get a certificate with multiple domain names called a SAN certificate, or get two certificates, one for www and one without. However, in the second case, you would need two web servers with different ip's to accomplish your task.
An alternate approach, one that use myself, is not to worry about it. Instruct users to go to regular http website and do the redirection yourself when SSL Cconnection is needed. This is what amazon.com does actually. They want you to browse http and they redirect you to SSL only when you buy something. Their certificate is also only valid for www, just go to https://amazon.com and you'll see their certificate is invalid without www
I am setting up a secure website with two subdomains:
https://www.domain.com
https://xxx.domain.com
I have acquired two SSL certificates, one for each of the subdomains (standard installation using nginx). I have also set up the root https://domain.com to simply redirect to https://www.domain.com.
Most of the time, this setup works fine. However, for some browsers (notably IE8 and Android), when accessing https://xxx.domain.com I get a certificate error, where the browser shows the certificate info for https://www.domain.com.
I suspect these browsers fetch the certificate from the root domain which then redirects to https://www.domain.com and hence the mismatch problem.
Can anyone advice on how to deal with this situation? Is buying a wildcard certificate the sole solution?
Thanks
If you're using the same IP address for both, then yes, some sort of multiple name cert is the only practical solution at this point. Alternatively, if you run the xxx site on a different IP address, things should be okay.
This shouldn't be an issue for just IE and Android, though. I'm not sure what's up with that.
(Hmmm ... maybe this should be on serverfault).
We are doing a project in Scala, using Lift to provide some REST style web services for clients (Java-script through AJAX). For some business reasons we decided to put it all under SSL but I'm am not sure where to start. Insights would be much appreciated.
Whatever server software is currently handling HTTP traffic (e.g. Jetty, Nginx, Apache...) almost certainly has some means of adding SSL support and disabling plain HTTP; try that first.
As for the basic mechanism of adding SSL support, it goes something like this:
Generate an RSA keypair (the key size should be at least 1024 bits). This step should prompt you to fill in some information about you, your organization, and the server's hostname ("common name" in X.509 parlance). It should also prompt you for a passphrase, which will be used to encrypt the private key.
The keypair consists of a private key (this is the part you shouldn't share with anyone) and a self-signed certificate, which contains, along with other metadata, the public key.
If you want to get a real cartel-signed SSL certificate, so that members of the general public won't see nasty warnings when they visit your site, you'll need to generate a Certificate Signing Request (CSR) from your keypair and submit that to an SSL certificate authority, who will create a certificate derived from your CSR, but signed with their private key. Luckily, in recent years, the SSL CA business has gotten extremely competitive, so pricing shouldn't be a major hurdle anymore.
If you're not planning to get a real cartel-signed SSL certificate, you can use the private key and self-signed cert as-is.
Either way, you need to tell your web server how to find the certificate (whether self-signed or CA-signed) and private key. Apache HTTPD prefers to keep the two things in separate files; most JVM servers prefer that they be encapsulated in a keystore. The best keystore format for general use is called PKCS#12, it's an industry standard. Making a PKCS#12 file out of a separate key and cert is a bit tricky, look on ServerFault if you can't figure it out. :)
You usually want to put the private key passphrase in the server's configuration file, so make sure that configuration file (and the file containing the private key) have the most restrictive permissions that will still work.
This depend on which application server you're running.
Jetty: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
Tomcat: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Glassfish v2: http://blogs.oracle.com/enterprisetechtips/entry/using_ssl_with_glassfish_v2
Glassfish v3: http://javadude.wordpress.com/2010/04/06/getting-started-with-glassfish-v3-and-ssl/
You're not sure where to start with which bit? The SSL?
Set up stunnel (or similar) in front of your webapp, and firewall your webapp off so that only stunnel can access it. Then your clients can only access your webapp over SSL, via stunnel.