Please I am trying to buy SSL certificate for my Exchange server 2016 deployment.
Where do I request and apply the SSL certificate, Edge Transport Server or Mailbox Server?
Can I apply the certificate on server, say Mailbox Role Server, then export it and apply it to the Edge Transport Role Server?
Also, should I request a wildcard certificate?
For Microsoft Exchange 2016, exchange server SSL certificates remain the best. They are also know as UCC SSL. It works like multidomain certificate because secures multiple domains & sub domains with single certificate. So I don't think you need wildcard ssl.
This type of SSL certificate comes with Free unlimited Server Licensing. So You will have to first apply UCC (Exchange SSL) at Mailbox server. It will remain good if you reissue the same certificate for Edge Transport Role Server inplace of export it and apply it again for Edge Transport Role Server.
Related
I have set the setting in cloudflare ssl/tls to Full (strict), but my server is connecting even with a self certificate. Why is this? My server is configured with Apache.
I want to prevent access to servers with self certificates.
If you set ssl/tls to Full, you will force CF to redirect traffic over ssl/tls. If your server is using a self-signed certificate you will need to upload a valid cert.
To avoid direct access, you need to set up authentication origin pull:
https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/explanation/
so that all traffic is evaluated before receiving a response from your server.
If you want your server to stop using self-signed certs, you can download a valid one from CF, and load it:
https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/
I just installed a Cloudflare Origin CA ssl certificate on my server. Because I have many domains on this server, I configured the certificate to protect them all, so I can use only one certificate for all my domains (domain1.com, domain2.com, etc...).
I went to check my ssl was working properly with the service whynopadlock.com, and I realized this service can list ALL of my domain names on the server by just accessing domain1.com? Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
I also noticed whynopadlock.com lists some domains in the certificate that are not mine. Does it mean Cloudflare is using the same certificate for many different users?
Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
All certificate subject alternate names are part of the certificate and are sent to every client that tries to connect securely.
There is no way to avoid it unless you want to use separate certificates for each domain.
I also noticed whynopadlock.com lists some domains in the certificate that are not mine.
Cloudflare states that this is normal:
Are Cloudflare SSL certificates shared?
Universal SSL certificates are shared across multiple domains for
multiple customers. If certificate sharing is a concern, Cloudflare
recommends a Dedicated or Custom SSL certificate.
Note that Cloudflare (as of Feb 2019) does provide dedicated certificates if you do not want to use a shared certificate.
There are several questions on stackoverflow regarding Akka, SSL and certificate management to enable secure (encrypted) peer to peer communication between Akka actors.
The Akka documentation on remoting (http://doc.akka.io/docs/akka/current/scala/remoting.html)
points readers to this resource as an example of how to Generate X.509 Certificates.
http://typesafehub.github.io/ssl-config/CertificateGeneration.html#generating-a-server-ca
Since the actors are running on internal servers, the Generation of a server CA for example.com (or really any DNS name) seems unrelated.
Most servers (for example EC2 instances running on Amazon Web Services) will be run in a VPC and the initial Akka remotes will be private IP addresses like
remote = "akka.tcp://sampleActorSystem#172.16.0.10:2553"
My understanding, is that it should be possible to create a self signed certificate and generate a trust store that all peers share.
As more Akka nodes are brought online, they should (I assume) be able to use the same self signed certificate and trust store used by all other peers. I also assume, there is no need to trust all peers with an ever growing list of certificates, even if you don't have a CA, since the trust store would validate that certificate, and avoid man in the middle attacks.
The ideal solution, and hope - is that it possible to generate a single self signed certificate, without the CA steps, a single trust store file, and share it among any combination of Akka remotes / (both the client calling the remote and the remote, i.e. all peers)
There must be a simple to follow process to generate certificates for simple internal encryption and client authentication (just trust all peers the same)
Question: can these all be the same file on every peer, which will ensure they are talking to trusted clients, and enable encryption?
key-store = "/example/path/to/mykeystore.jks"
trust-store = "/example/path/to/mytruststore.jks"
Question: Are X.509 instructions linked above overkill - Is there a simple self signed / trust store approach without the CA steps? Specifically for internal IP addresses only (no DNS) and without an ever increasing web of IP addresses in a cert, since servers could autoscale up and down.
First, I have to admit that I do not know Akka, but I can give you the guidelines of identification with X509 certificates in the SSL protocol.
akka server configuration require a SSL certificate bound to a hostname
You will need a server with a DNS hostname assigned, for hostname verification. In this example, we assume the hostname is example.com.
A SSL certificate can be bound to a DNS name or an IP (not usual). In order for the client verification to be correct, it must correspond to the IP / hostname of the server
AKKA requires a certificate for each server, issued by a common CA
CA
- server1: server1.yourdomain.com (or IP1)
- server2: server2.yourdomain.com (or IP2)
To simplify server deployment, you can use a wildcard *.yourdomain.com
CA
- server1: *.yourdomain.com
- server2: *.yourdomain.com
On the client side you need to configure a truststore including the public key of the CA certificate in the JKS. The client will trust in any certificate issued by this CA.
In the schema you have described I think you do not need the keystore. It is needed when you also want to identify the client with a certificate. The SSL encrypted channel will be stablished in both cases.
If you do not have a domain name like yourdomain.com and you want to use internal IP, I suggest to issue a certificate for each server and bound it to the IP address.
Depending on how akka is verifying the server certificate, it would be possible to use a unique self-signed certificate for all servers. Akka probably relies trust configuration to JVM defaults. If you include a self-signed certificate in the truststore (not the CA), the ssl socket factory will trust connections presenting this certificate, even if it is expired or if the hostname of the server and the certificate will not match. I do not recomend it
I have a server that has different services running on different ports. For example: https://hostname:9000.com or wss://hostname:4536.com, etc. Now what will be the single right SSL certificate that could secure all those services?
I read about WildCard Cerificates that secure all the sub domains on a domain. Would trying a WildCard Certificate the right thing to do in this case here?
Is there a way to secure the transport layer without any server certificate?
I read RFC 4492 and it is saying there is a key exchange algorithm name ECDH_ANON which does this, but on many of the links I found that it is not recommended to use this as it is prone to MITM (Man in the Middle) attack.
I just want to mention that my server is not public and my server and clients are in the same local subnet. My server is accepting connection on websocket.
What are the options if I want to secure my transport layer? I don't want to do it by manually encrypting the payload.
You could use a solution called TLS-SRP, if supported by your server and client(s). But probably more common is to just install a self-signed server certificate for your local system, or set up your own CA and issue your own cert to the server and install the CA's root cert as a trusted root on your clients.