Let's Encrypt requires Internet connectivity, but that is needed by the EFF ISRG who run it. Certbot (which runs on your computer) communicates with Let's Encrypt to issue and renew certs and does require connectivity from your computer.
A valid domain name (in the case of Let's Encrypt) is a domain you set up which can be resolved by the global DNS ...
Add a reverse proxy in front of the app and configure HTTPS on this proxy. Conveniently, you have Apache running which can happily reverse proxy for you.
As it currently stands, you can't use port 4040 as that's already taken by the app, so unless you can change the app's port or get it to bind to localhost (127.0.0.1 etc) only, then you'll have to run this ...
First of all, reinstall the server, because :
This one might be compromised and can't be trusted anymore.
Windows is secure by default, and maybe someone lowered the security settings of your server, hard to tell if there are no documentation.
You can take a look at this canonical question: How do I deal with a compromised server?
Check the Windows ...
This behavior sounds a lot like an HSTS (https://en.m.wikipedia.org/wiki/HTTP_Strict_Transport_Security) header was set for the domain. The good news is that you can simply stop applying it and the effects will eventually go away. The bad news is that it’s usually set to at least six months, and the only way to stop it earlier is to have all clients clear ...
The reason here is that when you make the request to IP address, TLS Server Name Indication field contains the IP address of the host, not the domain.
The server you are connecting has different virtual hosts defined for IP address and different domain names. The virtual host defined for the IP address does not provide the service you are looking for.
Please note that the automatic Let's Encrypt certificate provisioning will not begin until after your server has been submitted and either approved or accepted for use. The HTTPS test on the Server Tester can be ignored during the initial submission period.
I believe your other questions would also ...
Because they are exactly the same.
HTTPS is HTTP with added encryption, but the actual application protocol doesn't change; the requests and responses between clients and servers use the same syntax and status codes.
You can think of it as speaking English on a secure phone line vs. an insecure one; regardless of the line security, you'll still be speaking ...
You can define multiple VirtualHosts for the same port, you just have to set different ServerName directives for each.
If you want my.company.com to be the application at port 5000, and my-v2.company.com to be the application at port 5001, I'd suggest that you go with a configuration like this:
# Enable name-based routing on port 80 and port 443
Enable HTTPS. Either on the same web server running the app (pretty sure Azure can do this), or a separate reverse proxy, either would be fine. Issue a new certificate if necessary, x509 certs are cheap or free.
HSTS and HTTP insecure warnings are the browsers trying very hard for HTTPS everywhere.
Absent any explanation of why you can't do HTTPS, it will ...
You can generate a certificate on the VM with Powershell:
This first command will create a SelfSigned Certificate, stored in the machine's personal store.
$cert = New-SelfSignedCertificate -DnsName "service.location.net" -CertStoreLocation "cert:\LocalMachine\My"
Then, this command will export the certificate in c:\temp (...
Using HTTPS on Varnish isn't that hard. Although Varnish doesn't natively offer TLS, it facilitates TLS termination.
In 2015 Varnish released Hitch, a very powerful TLS proxy that handles terminates TLS and forwards unencrypted HTTP traffic to Varnish.
You can download the source from the Hitch website and compile it on our server. If you ...
It depends on requirements and resources, if you have On-Prem or baremetal, etc.
No requirements to secure traffic
If there are no requirements regarding securing client traffic inside the cluster, you can terminate client SSL connection on ingress-controller and use HTTP between the Pods.
If there is a need to secure client traffic ...
DNS isn't concerned with the actual URL you're trying to reach, only the domain name (i.e. www.example.com). In other words, your computer/browser isn't going to tell the DNS server the entire URL. That's reserved for the actual web server (nginx, Apache, etc). Remember, there's other reasons to do DNS lookups that are not related to web sites.
Are there ...
I believe what you mean is some kind of web interface to Azure Storage?
You could maybe leverage a tool like this:
You would need to host it in WebApp, but it might provide what you need? Or at least could be extended.
Alternatively the Azure Portal itself has a native web browser interface if it's just ...
As mentioned in a comment, the solution is to use DNS challenge validation, like here: How to use Let's Encrypt DNS challenge validation?.
First remove your previous certificate (if needed) with:
Then generate a new certificate with a DNS challenge:
certbot-auto -d *.example.com -d example.com --manual --preferred-challenges dns ...
Yes, to perform any of the challenges involved in creating new certificates, and that's it.
A 'valid domain' is just means 'not an IP address'. Let's Encrypt, like most issuers, will not use IP addresses as the subject of the certificate; it must be a domain.
All Certbot does is create certificates for whatever domain names it sees in your apache / nginx ...
Sort of - but not totally, and not if the remote end is compromised.
Assuming your traffic is https and not something else, its very difficult to intercept the payload, however there is low hanging fruit that can still be detected 2 ways - your DNS requests.
These can be detected from queries using standard DNS infrastructure (and indeed care needs to be ...
You can use Apache ab to load test your server. Use it like this:
ab -k -c 350 -n 20000 -p content.json -T application/json example.com/
This will command for example will fire up 350 simultaneous connections until 20 thousand requests are met.
The same RewriteRule for http and https should do the trick, put them first if there are others. I prefer mod_rewrite over mod_alias.
RewriteRule ^/$ https://example.com/app1 [R=301,L]
Gerard's answer preferring mod_rewrite over mod_alias leaves an illusion that this couldn't be achieved using mod_alias. According to Apache's official documentation:
When not to use mod_rewrite
mod_rewrite should be considered a last resort, when other
alternatives are found wanting. Using it when there are simpler
alternatives leads to ...
Yes and no:
User Agent headers
In general both actual browsers and libraries commonly used by developers will set a User-Agent header identifying the “browser” or library.
A request without a User Agent header is most likely generated by code rather than an actual web browser.
The commonly used libcurl library for instance does not set a default User Agent ...
Regarding status codes, HTTPS is no different to HTTP: the protocol itself (and thus the attached status codes, error codes, syntax, handling, …) remains untouched.
HTTPS is simply HTTP where the protocol is encrypted (either via TLS or—previously—via SSL), so there is no change in the content.
Why don't you run your own?
For httpbin.org, the source code is available on GitHub and it's also available on Docker:
docker pull kennethreitz/httpbin
docker run -p 80:80 kennethreitz/httpbin
See http://httpbin.org for more information.
Also, you could achieve what you ask for i.e. "presented somehow" e.g. with a PHP one-liner:
Also not sure why just hitting yobuzzer.com with the cname is not working, but dev.yobuzzer.com works
You can't use CNAME on root domain (yobuzzer.com); you can only use CNAME on subdomain (www.yobuzzer.com, dev.yobuzzer.com, etc). Root domain should only use A or AAAA.
Though, on Cloudflare, they can flatten CNAME on root domain, technically querying A ...
The warning you get is caused by the ServerName directive in the main configuration file. You specify a name with a port:
which is the default port for SSL, but SSL is not enabled at the server level (it is enabled in a VirtualHost). Replace it with:
and the warning disappears.
Remark that the ServerName,...
If the API host has changed, its likely that the owner has implemented a newer SSL configuration which is now longer compatible with your Charles proxy.
I would suspect SNI support may be the issue here.
A lot of people rely on SNI now to allow them use multiple SSL certificates on the same infrastructure, but that means support for non-SNI implementations ...