We have purchased a valid wildcard SSL certificate from Entrust.
Let's say it is a wildcard certificate that covers *.ourcompany.com
I understand we can use this certificate directly on our web services.
Since, it'll be a lot of servers, we wanted to lock down a little bit the wildcard certificate.
Can we use this wildcard certificate to sign separate set of certificates for subdomains like service1.ourcompany.com, service2.ourcompany.com, etc. ? (without involving Entrust for each of those subdomains/ subservices).
Pros:
If one of those services gets compromised, it'll be limited to that service only ;
We don't have to reach out to Entrust for each of the subdomains (as there could be a lot of them) - also in terms of cost ..
In other words, I'm thinking if it's possible to treat a wildcard ssl cert as an "authority" to validate ssl certs in subdomains. (be part of SSL Certificate Chain)
Thank you.
Related
To begin let's say I have this configuration :
mywebsite.com is related on machine 0.0.0.1 (with ssl certificate)
cloud.mywebsite.com is related on machine 0.0.0.2 (without ssl certificate)
can I ask for a new SSL certificate for "cloud.mywebsite.com" or this will create issues because of domain/subdomain ?
Thanks for the response.
Instead of asking for a new SSL Certificate, you only need to get Wildcard SSL Certificate that will secure your main domain as well as its all sub-domains. For example:
If you get Wildcard SSL certificate for *mywebsite.com then it will secure,
https://cloud.mywebite.com
https://mail.mywebsite.com
https://photos.mywebsite.com
https://anything.mywebsite.com
So, you will not have to manage multiple SSL certificates for your main domain and its sub-domain. Wildcard SSL certificate will reduce the hassle of server administrators for multiple SSL management. I suggest you to read this article, which will give you clear understanding of Wildcard SSL Certificate.
I've been googling like mad trying to figure this out, but the answer doesn't seem to be clear, or at least, it seems like there are contradictory answers.
I'm tasked with setting up an Apache web server with 2Way SSL authentication. We use verisign to get our certificates, so we have a certificate for the web instance with the correct hostname details, signed by verisign, and an intermediate certificate from verisign. This all works very well.
Now, we need to set up a 2Way SSL connection. The initial expectation is that the client will manage their own certificates, and provide them to us for authentication. More than one client may be connecting, and they should each have access to different resources when they connect.
From what I've read, I'm not sure how this would be done...
This is a pretty good overview, but in this situation, they are using self-signed certificates: https://security.stackexchange.com/questions/34897/configure-ssl-mutual-two-way-authentication
Using these details, it would seem like we would have to make the trusted CA point to the certificate authority that signs the client's certificate.
Is it possible to use the client certificate as the trusted CA (even though it isn't self signed, but signed by a CA) or would we have to put a trusted CA from their signer (and at that point, would a CA bundle that includes all the client certificate authority CAs work?) on the server and then use the SSLRequire statements to limit access to specific details of the certificate?
As a followup, can we use the SSL Certificate that we get from verisign to sign client certificates?
So, after several more hours on google, and some testing, I was able to figure out what I needed to.
If I want to use a certificate signed by verisign or some other public CA, I would have to copy their public intermediate certificate (the one that they use to sign the client certs) to my server and specify it as the SSLCACertificateFile in the configuration. The caveat is that then any cert signed by that CA would be accepted, and that's where the SSLRequire directives can used to narrow that down to specific certificates.
Using the SSLVerifyClient optional_no_ca directive would make it assume that the cert is trusted, even if it isn't, and then I would have to use SSLRequire directives to verify the details are correct, however, anybody could create and sign their own certificate with those details and there would be no way to tell.
Creating my own self signed CA certificate, and then using that to sign the client certificates and issuing them to the clients is the only way to both ensure that the cert isn't a forgery and not requiring SSLRequire directives to ensure that only the people that I specify can connect.
Please comment/correct me if I'm wrong on any of this.
Use:
SSLVerifyClient optional_no_ca
In your Apache config. This will request the client certificate but not validate it against a CA. It will then be up to your local script to examine the resulting environment variables set by Apache such as 'SSL_SERVER_S_DN' and decide whether to allow the request or not.
These mod_ssl environment variables are also what your code needs to look at when determining what resources the client can access.
The full documentation is here mod_ssl although you probably found that already.
A note on client certificates. If you did want to use a CA and leave it to the clients, they may all use different CA's and you would have a job maintaining them all on your server. It would be much better to trust a single CA.
The advantage would be that then you could use the build in SSL support to do all your certificate checks and not write your own solution.
You could enforce a single CA by specifying an on-line provider and using email signing certificates to identify clients. These would work fine, just the Certificate Subject would be an email address instead of a domain name.
Or you could set up your own CA and sign client certificates yourself. This is not too difficult and gives you complete control. Either route would require you to add the CA root certificate (plus intermediates) to a file Apache can read and point 'SSLCACertificateFile' to it.
When I try to upload an SSL certificate for my Bluemix custom domain, I receive this error message:
BXNUI2072E: The intended host name, *.<custom_domain>, is not a subject within the certificate.
How can I go about getting my certificate uploaded successfully and avoid this error?
Thanks!
I learned that the problem here was due to the certificate I was using, which was for a single, specific domain. Bluemix supports only wildcard certificates, that's a key point.
I got around this by replacing my single domain certificate with a wildcard certificate.
To generate a wildcard certificate, I needed to specify a wildcard domain by adding an asterisk (*) and a period (.) in front of my custom domain name.
In the example that follows I used OpenSSL to generate a self-signed wildcard certificate. I've generalized the example but simply specify a wildcard domain for the Common Name field.
Common Name (e.g. server FQDN or YOUR name) []:*.<custom_domain>
I tested and succesfully got this to work for both a self-signed certificate and a certificate signed by a certificate authority.
My webhosting company offer free shared ssl certificates that I would like to take advantage off but here's the issue:
the SSL url looks like this
https://web125.secure-secure.co.uk/myurl.com
I'm worried that when my customers make a purchase and they see that the URL isnt myurl.com they might be cautious or hesitant to continue the transaction.
so is it possible to map the ssl domain to https://secure.myurl.com
if not, are there any alternatives (apart from obviously buying my own certificate)
No it is not possible. The only alternative is to pay for a certificate unless you don't mind your users getting warnings in their browser.
The reason it is free is because your hosting company have paid for a wildcard certificate from a Certification Authority (CA) i.e. *.secure-secure.co.uk in which they can have any sub-domain. e.g. mycompany.secure-secure.co.uk.
If you want a certificate for your own domain e.g. mycompany.co.uk or you want a wildcard certificate to do stuff like services.mycompany.co.uk or extranet.mycompany.co.uk then you need to buy one, a wildcard certificate will be more expensive.
A certificate can only be used to validate a particular URL so you are basically paying a trusted source e.g. a Certification Authority such as VeriSign or DigiCert to vouch for your identity so users can know that when they hit https://www.mycompany.co.uk that traffic is encrypted and only the owner of mycompany.co.uk can decrypt it.
You're unlikely to a find a free source for valid SSL Certificates because the Certification Authorities will have had to pay to have their own identity verified and probably had to pay to have their own certificates built into operating systems to create a chain of trust. When you don't have a chain of trust or when a certificate URL does't match the URL you are visiting, this is when you get the big scary warning in your browser.
I guess it can't be done, but if so, I'd like to know why.
Let's say I get an SSL certificate for example.com from one of the official certificate authorities around. Let's also say I'm running a.example.com and b.c.d.example.com and would like to have SSL certificates for those as well.
Can I use the example.com certificate to issue certificates for a.example.com and b.c.d.example.com myself? And will they be recognized by users' browsers? If not, why not?
(My guess that it can't be done is because it would break the very lucrative wildcard cert business model, wouldn't it?)
Clarification: can't I act as a "self-signed" certificate authority using the keypair for which I obtained the official cert, and simply add my official cert in the validation chain?
You cannot use Your certificate to issue other certificates, because the purposes of the
certificate are encoded in Your certificate and "Certificate Authority" is certainly not included in that list.
Web browsers check the "certificate chain" beginning from Your certificate, the certificate that was used to sign it, the signer of that certificate etc.
Your certificate must match the current use case (mostly "identify web site") and all signing certificates must include the "Certificate Authority" flag. The last certificate must be known to the browser (root cert).
As You already guess, wildcard certificates might help in Your case.
You're correct, you cannot issue certificates from a certificate. You need a Certificate Authority to issue certificates.
The whole point of a Certificate Authority is that they are a trusted 3rd party. CA's like Verisign are trusted by default by most browsers so that you dont have to manually accept certificates from them. They have what is termed a trusted root certificate.
If you create your own Certificate Authority and start dishing out certificates, web browsers will not know you and hance not trust you. The user will be prompted.