Changing Netlify DNS results in SSL_ERROR_BAD_CERT_DOMAIN "Your connection is not private" in Chrome
This was after the domain configuration was set (i.e. a change of settings)
Solution was to renew certificate after changing the domain information (which at this time was not specified in the docs)
Options found under:
Site settings > Domain management > HTTPS > Renew Certificate
Related
Let's say my Caddyfile defines two sites: a.example.com and b.example.com.
What should I do so that any subdomain other than these two is redirected to a.example.com? For example, going to c.example.com or xyz.example.com should redirect to a.example.com
In other words, I want something like a 404 rule but for non-existent subdomains rather than non-existent files.
Point your DNS A/AAAA records for *.example.com to your server.
a.example.com {
# handle here
}
b.example.com {
# handle here
}
*.example.com {
redir https://a.example.com
}
You handle the a.example.com and b.example.com domains as you normally would, and set up a redir for *.example.com to https://a.example.com. Note that Caddy will automatically setup a redirect from http to https so that isn't needed.
Because you are using a wildcard domain in your Caddyfile, you can either use Caddy's on-demand TLS (which will fetch a certificate for that subdomain whenever such a request is received) or use a wildcard certificate (which requires the DNS challenge).
On-demand TLS
*.example.com {
tls {
on_demand
}
}
There are some pitfalls to this approach which make wildcard certificates more attractive:
Clients can abuse the setup to get as many certificates as they want, resulting in disk / memory exhaustion.
Rate limiting by certificate authorities
Wildcard certificates
*.example.com {
tls {
dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN}
}
}
To use the DNS challenge, you need to
Use a nameserver that supports programmatic access
Build Caddy with a provider for that nameserver configured. For example, for Cloudflare you could build with https://github.com/caddy-dns/cloudflare (xcaddy build master --with github.com/caddy-dns/cloudflare) and save the token in the environment variable CLOUDFLARE_AUTH_TOKEN.
I'm trying to set up an API Management Gateway using a custom domain. However, when I go to test it out, I get an SSL error. I am not sure if I've missed any steps or I've misconfigured my custom domain. The API returns a 200 response when I use the default Gateway URL but returns a 400 when I use my custom domain.
Any help in this domain is appreciated. Thanks
I've described the steps I've followed below:
Steps followed to create a custom domain:
Setup a CNAME for my custom domain api.something.com in Route 53 with Value as .azure-api.net
When creating a custom domain, I added my PFX certificate to the custom domain. When creating my certificate, I set CN="*.something.com. Additional settings such as Negotiate Client Certificate: false and Default SSL binding: true
Created an API with the suffix app1 so that my API is reachable at api.something.com/app1
Now, when I try to test it out through the portal, I get the error
HTTP/1.1 400 Bad Request
content-length: 123
content-type: application/json
vary: Origin
{
"error": "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
}
This is the request header. ALs I've turned off Require Subscription Key but I'm not sure why the subscription key is still included in the header
GET https://api.something.com/app1/api/heartbeat HTTP/1.1
Host: api.something.com
Ocp-Apim-Subscription-Key: xxxxxxxxx
Ocp-Apim-Trace: true
I'm trying to send a GET request using the Insomnia app to a NodeJS server app -- I didn't write the app but have joined the team.
Although I get a reasonable JSON response when I hit the URL -- https://127.0.0.1:9999 -- from the browser, I get the error "Error: Peer certificate cannot be authenticated with given CA certificates" when I'm using Insomnia. Using a Mac, MacOS 10.12.4. Node v6.3.1.
The Insomnia timeline says:
* Preparing request to https://127.0.0.1:9999/
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 2 cookies
* Hostname in DNS cache was stale, zapped
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 9999 (#8)
* WARNING: using IP address, SNI is being disabled by the OS.
* SSL certificate problem: Invalid certificate chain
* Curl_http_done: called premature == 1
* Closing connection 8
Thanks for any help!
There is little documentation on how Insomnia handles certificates. As long as they are normal certificates that are signed by a typical CA authority there is typically no problem. Since you also refer to your loopback address (127.0.0.1) I assume that you're also testing with a self-signed certificate.
I noticed that Insomnia uses the Mozilla list of certificate authorities. It does not use the list of your operating system.
The list is stored in a text-file in a directory like C:\Temp\insomnia_5.12.4. In my case it was for example 2017-01-18.pem. You can add your own signing authority certificate to this file.
I didn't look into how stable this file is or how it is created.
You can also workaround the certificate errors by disabling them in your settings (settings > Validate SSL Certificates).
I create a Node.js app with HTTPS protocol. I followed a tutorial from nodejitsu https://docs.nodejitsu.com/articles/HTTP/servers/how-to-create-a-HTTPS-server/
But when I sent a request to the server, I git the following error:
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
When I opened from Chrome, I can only access the page after pressing advanced and proceed to the page.
This is what I filled when generating the certificate:
Country Name (2 letter code) [AU]:ID
State or Province Name (full name) [Some-State]:East Java
Locality Name (eg, city) []:[my city name]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:[some string]
Organizational Unit Name (eg, section) []:[some string]
Common Name (e.g. server FQDN or YOUR name) []:[IP address of the server (Azure server) without port and 'https://']
Email Address []:[my personal yahoo email]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:[empty]
An optional company name []:[empty]
The app is hosted on Azure server.
How can I fix it?
You are using a Self-Signed certificate which is causing verification failure. You need to get a signed certificate to remove the validation error.
I've seen both this and this — same problem, different question.
I'm trying to connect my Windows 8.1 Store app to an ASP.NET Web API web service, secured over HTTPS using a self-signed certificate. It's a proof-of-concept application that will end up on < 5 different machines and seen only internally, so I was planning to just install the certificate as trusted on each of the target machines.
When I try this on my development setup, both HttpClient APIs fail to establish the trust relationship when calling the service.
Windows.Web.Http.HttpClient exception: "The certificate authority is invalid or incorrect"
System.Net.Http.HttpClient exception: "The remote certificate is invalid according to the validation procedure."
My self-signed certificate (public-key-only .cer version) is installed in both the "User" and "Local Machine" Trusted Root Certification Authorities on the client. I'm really surprised that this isn't enough to get WinRT to trust it. Is there something I'm missing, or is there just no way to set up the trust relationship for a self-signed SSL certificate that will make HttpClient happy?
Details on my setup:
ASP.NET Web API
Azure web role running in Azure emulator
Cert issuer: 127.0.0.1
Cert subject: 127.0.0.1
Cert key: 2048-bit
Windows 8.1 Store application
Certificate (.cer file with public key only) installed in User\Trusted Root Certification Authorities
Certificate (.cer file with public key only) installed in Local Machine\Trusted Root Certification Authorities
Certificate (.cer file with public key only) added to Windows Store app manifest under "CA"
I am not asking for a workaround to configure HttpClient to accept self-signed or invalid certificates in general — I just want to configure a trust relationship with THIS one. Is this possible?
You should be able to find out what is the problem with the certificate by doing a request like this:
// using Windows.Web.Http;
private async void Foo()
{
HttpRequestMessage request = null;
try
{
request = new HttpRequestMessage(
HttpMethod.Get,
new Uri("https://localhost"));
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.SendRequestAsync(request);
}
catch (Exception ex)
{
// Something like: 'Untrusted, InvalidName, RevocationFailure'
Debug.WriteLine(String.Join(
", ",
request.TransportInformation.ServerCertificateErrors));
}
}
Using a HttpBaseProtocolFilter you can ignore certificate errors:
// using Windows.Web.Http;
// using Windows.Web.Http.Filters;
// using Windows.Security.Cryptography.Certificates;;
HttpBaseProtocolFilter filter = new HttpBaseProtocolFilter();
filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.Untrusted);
filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.InvalidName);
filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.RevocationFailure);
HttpClient client = new HttpClient(filter);
HttpResponseMessage response = await client.SendRequestAsync(request);
The piece I was missing turned out to be that the certificate wasn't in the list of of IIS Server Certificates on my local machine!
Opening IIS Manager and checking out the Server Certificates section, I did find a 127.0.0.1 SSL certificate already set up by the Azure emulator:
CN = 127.0.0.1
O = TESTING ONLY
OU = Windows Azure DevFabric
However, my own self-signed certificate that I made outside of IIS, also with CN=127.0.0.1, was not in the list. I imported it, and now my Windows Store app's HttpClient connects happily (certificate warnings went away in Chrome and IE as well!)
If anyone can firm up the technical details on this, please comment — this fix feels a bit magical and I'm not sure I can pinpoint precisely why this worked. Possibly some confusion on my part between the two certs for 127.0.0.1, even though the thumbprint I had configured in my Azure project was always the one I was intending to use?