I have only just begun using Insomnia for testing some REST calls.
I got a certificate issue because the Common Name of my certificate on the server does not match the Hostname that is used to reach the server.
I want to know, if there is a way I can disable hostname verification in Insomnia ?
I came across this link that mentions the flag which is to be used, but I am currently not sure how to configure Insomnia with the flag
https://docs.oracle.com/middleware/11119/wls/WLACH/taskhelp/security/DisableHostNameVerification.html
At this point, I am also trying to re-generate the server cert with appropriate SAN but due to some restrictions, my host IP might change, so I am not sure if this is a solution that I can use every time I have to test some calls.
Please help if you know how we can configure Insomnia to skip hostname verification check. Thanks.
Insomnia also has the option to turn off certificate verification.
Go to “Preferences”,
Navigate down the general preferences to find and uncheck “Validate certificates.”
I was able to verify after adding SAN to the cert csr.
Tag to be used in the csr for adding the SAN is :
subjectAltName = IP:<>
or
subjectAltName = DNS:<>
Multiple SANs can be added to the cert.
But, there is no way that I could find to disable hostname verification on Insomnia.
Although if you want to skip validation of a cert altogether, then you can uncheck "Validate Certificates" option in the Preferences.
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.
Decided to move from a shared hosting platform to an AWS based Hosting Environment (Acquia Cloud specifically). This environment doesn't offer e-mail services so the client kept the shared hosting to continue using that for email (they didn't want to spend the extra $2400 per year for G Suite Email Hosting).
In order to achieve this, we worked with the new host to use the shared site as a pass through so that the emails still go there, and the web traffic goes to the new server.
The nameservers go to the shared host. We have a DNS Cname www.example.com pointed to the new AWS server and the A record pointed at the shared host. It was the only way to keep the email still running. When we pointed the A record, that's when email went down. This was the suggestion from the hosting company.
So now if they go to http://example.com, https://www.example.com, http://www.example.com and www.example.com it all works fine, no problem. However if they go to https://example.com they get this issue right here:
1:
When we moved to the new host, the SSL certificate went with it. This causes some Search Engine Issues. I have an .htaccess redirect set up, but it still gives that error.
This is what myself and both hosting companies could best come up with, and it's not a great solution.
Is there a solution other than:
Carrying an SSL Certificate for both accounts
Moving email to a 3rd party provider like gmail
If there isn't we are going to go with one of these options, but I figured I'd ask first.
The only issue here is your certificate does not have example.com in your certificate SAN (Subject Alternative Name). By default, you should get this in your SAN but few CA don't provide it under SAN unless and until you tell them. Kindly find the image for your reference. If you have windows OS just save your certificate file in .crt or .cer format to view the SAN.
Else you can use below command if you Linux OS and the certificate is installed on the server
openssl s_client -connect website.com:443 | openssl x509 -noout -text | grep DNS
It will list the SAN
Is there a reason why Facebook doesn't allow LetsEncrypt signed certificates in their "app development" section?
I keep getting this error:
(For the untrained eye, this is me trying to setup a webhook for new messages notifications)
Blurred out the host, but it's a valid host and using chrome or firefox on Linux and Windows doesn't give any errors.
SSLLabs also says the site is perfectly valid.
Running curl https://... on my own host, sure enough I get the same error,
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
So my question is, why have Facebook (that openly supports LetsEncrypt) decided to use default curl CA bundle to verify the callback-url of an app? If that doesn't allow LetsEncrypt?
It appears to be counterproductive to me.
Is there a way around this?
SSLLabs also says the site is perfectly valid.
It shows a warning in orange, that the certificate chain is incomplete.
Your server should present all necessary intermediate certificates as well, in addition to the certificate issued for your domain. (Which was simply forgotten here by mistake.)
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.... :(
The quiz can't be viewed by any other users, unless the "Secure URL" is updated. But I can't figure out how to do that.
This simply means you must have an SSL certificate on the domain that hosts your canvas page. I would recommend rapidSSL.
Here is a general overview of what this entails: http://webnet77.com/SSL-certificates.html
Here is what we do:
get yourself host account with dedicated IP or better linux dedicated server
ask your host to generate Certificate Signing Request or do it yourself use openssl (don't know how to do it on windows)
get cheap ssl certificate (like rapidSSL) 9.90 per year or something just domain verification, google it.
send them your CSR
wait like 10 minutes
find your cert in your inbox attached
install it according to your server (Apache uses mod_ssl)
test it