I have moved a site from an ISP to a private server and need to move my SSL certs over.
However, the ISP gave me 4 certs for the site in question, so I am unsure of the match of three of the four files, as well as confused about why I have four:
AAACertificateServices.crt
[THE DOMAIN I AM MOVING]_com.crt
SectigoRSADomainValidationSecureServerCA.crt
USERTrustRSAAAACA.crt
Spending time to research the procedure of installing the certs for a site up and running on Ubuntu 20.04 with Apache2, all the online docs I found will have me edit the virtual host block of the Apache2 site conf file thusly:
<VirtualHost xxx.xxx.x.x:443>
DocumentRoot /var/www/[THE DOMAIN I AM MOVING]
ServerName [THE DOMAIN I AM MOVING]
SSLEngine on
SSLCertificateFile /path/to/[THE DOMAIN I AM MOVING]_com.crt
SSLCertificateKeyFile /path/to/privatekey.key
SSLCertificateChainFile /path/to/intermediate.crt
</VirtualHost>
There is one obvious .crt file that matches here, but I am not sure of the placement of two others, and entirely unsure why I received 4 files instead of 3.
So, I have a couple of questions:
Why the forth file?
Which two of the remaining three are the privatekey and intermediate files?
Is there a standard way to identify the purpose of each file?
I have tried a number of combinations, but cannot get these files to work. The ISP that originated the certs is no help, as they have WHM and cPanels that make this an easier task, but my server does not have either so I am stuck with manual entries.
I have successfully installed a Comodo cert for one of two sites I have on my private server, so I am OK for now using that one, but it remains a mystery and a problem: not being able to EASILY transfer certs from a shared server to a private server.
I will continue the effort and post any positive results.
So, the "answer" here is: This operation is difficult and there is no easy solution I have found, to date.
Related
I've purchased a TLS certificate from godaddy for a domain (say somebeta.com - actual is different). The DNS points to an AWS EC2 Linux server which I operate. The httpd web server on this EC2 serves the REST API requests.
I've installed the certificate on the AWS EC2 server which points to beta.com, and at no place in httpd.conf or ssl.conf have I specified the ServerName directive. Every thing works nicely, https://somebeta.com works, green color appears, all is good.
Now I create a new subdomain routing on godaddy DNS, by pointing alpha.something.beta to another EC2 instance. When I install this certificate on another EC2 server, I get following in ssl_error_logs:
ip-<Some IP>.ap-south-1.compute.internal:443:0 server certificate does NOT include an ID which matches the server name
I looked on SO, and found that the hostname of the machine should match the CN in the certificate. If it does not, then SSL/TLS would fail (I believe mod_ssl checks and fails this).
My question is, I've not set the hostname of the actual somebeta.com EC2 server, but still the SSL/TLS works great. How is it happening? Does mod_ssl do some intelligence to figure that the localhost is actually pointing to somebeta.com (by doing DNS/etc) and that's why it works?
Please don't close the question too early, I understand the working of SSL/TLS in its entirety, I just need to know how the thing is being validated by mod_ssl in httpd. Does the absence or presence of ServerName directive matter always, or only sometimes?
I recently successfully installed Letsencrypt, and my site seems to work well with https. When i visit it e.g https://example.com, no errors/warnings appear. However when i visit it with https://www.example.com, (including www) in all browser I get some sort of warning, for example, in chrome:
Your connection is not private
Attackers might be trying to steal your information from
www.example.com (for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID
And in opera:
Opera cannot verify the identity of the server "www.example.com", due to a certificate problem. The server could be trying to trick you.
My server runs apache and https works wonderfully when not www. In /etc/letsencrypt/live/www.example.com/ I have:
cert.pem chain.pem fullchain.pem privkey.pem
Would appreciate any help and do ask if you require further detail. Hope this helps others too.
This is saying the cert is not valid for www.example.com.
Could be several reasons for this including:
You didn't specify this when creating the cert and only asked for example.com. Though weird that LetsEncrypt has put it in the www.example.com directory, suggesting you did do this right.
You made a typo in the domain name.
You included the protocol (http/https) in the domain name and/or the port (443). These should not be in the cert request and just the domain name.
You have a separate cert for example.com and www.example.com and have only one configured in Apache. Most sites use the same cert for both and have both versions valid for the domain.
Probably best to view the cert to rule out some of these. This can either be done in the browser by clicking on the green padlock when viewing https://example.com and/or running this command:
openssl x509 -in /etc/letsencrypt/live/www.example.com/cert.pem -text
You can also use the https://www.ssllabs.com/ssltest/ online tool to view your SSL setup (in fact I'd recommend to do this anyway!).
It might be late but the problem is there because you didn't mentioned www.exemple.com in the certbot setup.
to add the domain to your certificate just run this command
sudo certbot --expand -d www.camelges.com
then restart your apache server
if you are on ubuntu service apache2 restart
Reference: https://certbot.eff.org/docs/using.html#re-creating-and-updating-existing-certificates
From their post here:
Can I get a certificate for multiple domain names (SAN certificates)?
Yes, the same certificate can apply to several different names using
the Subject Alternative Name (SAN) mechanism. The Let's Encrypt client
automatically requests certificates for multiple names when requested
to do so. The resulting certificates will be accepted by browsers for
any of the domain names listed in them.
If your common name is example.com you will need to set a SAN as www.example.com when generating the certificate request.
Adding to the points from BazzaDP, (From my own experience).
5) if you have virtual configuration files where ServerName is same but ServerAlias is different then you will be getting same err, hence you should change ServerName.
You need to generate certificate for both URL's, by example:
sudo certbot --apache -d mydomain.com,www.mydomain.com
I run a local development web server for testing out code changes.
Often I have to test my local changes with remote services that can only connect securely to another domain.
e.g. https://external1.com will only talk to https://someOtherDomain.com, but I've got to test integration of my new code changes with https://external1.com
While I've got a setup configured that works, it seems complex, and took a bit to get setup right. It seems to me that many developers would want to do this same thing, so my question is this:
Is there an easy way to proxy my local webserver as https://someOtherDomain.com ?
EDIT: So maybe this should be asked this way - Does a command line or GUI tool exist that you can pass a local port and a domain name, and it serves your local port securely over https://someOtherDomain.com - no config or SSL cert creation required? Of course it'd be nice if the SSL cert could be replaced through configuration if need be, but by default, it'd work automatically, by using a precanned SSL cert. And even though I'm using Apache, I'm looking for a solution that actually doesnt use Apache - it uses something else. Why? Because I want this solution to work well with any other webserver that's being used by people on our team - as we all run different stacks, and I'd like to be able to let any of us securely serve our sites without having to configure each webserver individually.
Here's my current setup for taking my local webserver and serving it up at https://www.someOtherDomain.com
To test this locally, I've been:
editing my hosts file, and adding an entry to make www.someOtherDomain.com point to my local machine, which of course is running my dev server. This makes it so my local site is now available at http://www.someOtherDomain.com
127.0.0.1 www.someOtherDomain.com
Running Apache with a SSL Cert setup and mod_proxy to redirect all https requests to my local http server, thus making my site available at https://www.someOtherDomain.com. Here's my Apache config for this:
ServerName www.someOtherDomain.com
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
<Proxy balancer://mycluster>
BalancerMember http://localhost route=1
</Proxy>
ProxyPass / balancer://mycluster
ProxyPassReverse / balancer://mycluster
SSLHonorCipherOrder On
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite RC4-SHA:HIGH:!ADH
# Rewrite all http requests to https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
I run this on a mac, but am interested in solutions for linux as well. I've seen various Man in the Middle proxy's that sound like they'd work with some configuration... but I'm looking for something really simple to install and run - not just for me, but something I can tell team members about too, as we may all have to do this a lot in the future.
IMPORTANT NOTE: My local webserver isn't running on Port 80, though I've put it this way in the above example, to keep it simple. I understand port 80 on a mac is a bit special, but am very happy with solutions that work fine on all ports but port 80.
I think mitmproxy can do this for you, as least on linux and os-x. I haven't tried it myself but this question seems to show how it is done. It's still not a trivial program though.
There are however other approaches, which I have used:
The first one is the most pretty simple one, create a DNS entry for develop.mydomain.com which points to 127.0.0.1 and a single certificate for a (sub)domain where you control the DNS. Spread that certificate to all your developers. They'll still need to setup SSL themself but they don't need to generate certificates anymore. It has the added benefit that everybody is developing against https://develop.mydomain.com which allows them to share the configuration.
For bonus points, create a DNS entry for *.develop.mydomain.com and a wildcard certificate and your developers can have different sites (e.g. https://project1.develop.mydomain.com and https://project2.develop.mydomain.com) on there local machine. (Contrary to what the internet sometimes tells you, name based virtual hosting works fine with SSL as long as the certificate is valid for all the named hosts). Since the domain is the same for everybody you can consider getting a valid wildcard certificate to get rid of the warnings.
Unlike the solutions below this works even outside of the office network, which may be relevant when people are working from home or at the customer.
Building on this you could also create DNS entries for the internal IP's of the developer machines (if those are fixed). This does add some work, but it means the ongoing work of a developer can be reached by others in the local network, which can be very convenient for demo's, testing on mobile devices, etc.
An other option is to configure a single machine to proxy for all your developers. Create a DNS entry pointing to the internal IP of this box on something like *.develop.mydomain.com, a matching wildcard certificate and configure that box once with the correct certificate. Now you can create a virtual host for each proxied server, and again, all sites will be reachable throughout the local network, but it does require the developer to have fixed ip addresses (or hostnames added to DNS through DHCP).
Combined with the ability of apache to include all files in a directory in it's configuration makes it trivial to create a script which adds a new site based on a template. All it has to do is write a new file based on the requested subdomain plus the destination and reload the apache config. This means something like a simple PHP script can do what you want the application to do.
If you want to expose your web on your local machine to the internet try Runscope Passageway, it's easy to setup and "just works" (from experience).
Another alternative is ngrok which I also used, but it didn't always work for me.
I am trying to host 2 sites on a single IP address and they need to be accessed via SSL however the majority of my users use Internet Explorer on Windows XP meaning using multiple SSLs with SNI may prevent them getting access.
I was wondering if I could use a multiple virtual hosts but still use a single SSL certificate and avoid SNI ?
Alternatively how feasible is it for me to install two Apache webserver instances, each its own DocumentRoot and own SSL certificate and for me to simply use the first Apache webserver as an entry point to entertain some requests and to redirect others to the other SSLed Apache instance ?
Could I potentially use the Windows Host file (Windows 2008 Server) to redirect incoming requests to the intended Apache Server instead of using VirtualHosts ?
Apologies if I have confused concepts.
You can try to purchase an X.509 certificate with two domains in it. I don't know what particular CAs do this, but I also don't see why they would refuse. You need to ask their support, though.
Your idea to redirect some requests to another server residing on a different port sounds good as well, though you will have to use two different certificates for different domain names, of course.
Finally if your second domain can be something like additional.mydomain.com , you have greater chance to buy a certificate issued for mydomain.com + www.mydomain.com + additional.mydomain.com (this can be a wildcard certificate or a certificate with additional subdomain names).
I am running a multi-language web store accessible from differents domains, that lead to different languages.
The apache configuration is quite complex and I would like to have one single file shared with all the stores. I had this in place until I had to introduce SSL.
When it comes to apache and SSL certificates I would need to do something like:
SetEnv is_es 0<br>
SetEnvIfNoCase Host .*es is_es 1<br>
SSLCertificateFile /etc/ssl/certs/spanish.server.crt env=is_es<br>
This is aparently not possible, apache tells me:
<i>SSLCertificateFile takes one argument, SSL Server Certificate file (`/path/to/file' - PEM or DER encoded)</i>
I was wondering if there is any workaround. My goal is to avoid having different copies of the same configuration and having to propagate manually any changes I want to make.
It is hosted on a dedicated server, so I am free to do any changes to the setup.
When you are on a https connection, the Host header is inside the SSL encapsulation, so you need the full SSL handshake before you check for an hostname for your virtualhost.
You should go for SSL certificates with SAN (Subject Alternative Names), this will allow that a single certificate for multiple hostnames. (or a wildcard cert)
All the main browsers supports it already:
http://www.digicert.com/subject-alternative-name-compatibility.htm
And you can get one of this certs from the majors CAs:
http://www.digicert.com/subject-alternative-name.htm
http://www.verisign.com/ssl/buy-ssl-certificates/subject-alternative-name-certificates/index.html
http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html