Up until recently, we were verifying domains for AWS SES DKIM by adding CNAMES to the root domain as per the AWS instructions.
Our DNS provider now no longer allows CNAMES to be added to the root domain (e.g. example.com) so we can't use this to verify DKIM for email addresses we typically use (which are generally in the format something#example.com).
Are there any other ways to verify domains for DKIM for SES without adding CNAMES to the root domain?
Related
I have an active SSL cert for "domain.com" that is hosted on Server1. If I have a mail service that is hosted on Server2 and uses the same domain root, "#domain.com", would I be able to use the same cert? Or do I need to buy a second SSL for the same domain on the mail server?
Your certificate's SAN (Subject Alternative Name) should either contain both of the target domains or a wildcard domain like *.domain.com.
Additionally, the private key must be copied from server 1 to server 2.
If you follow the suggestions above, you should be good to go.
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.
I am getting this message on my main site, after I setup a CloudFront distribution. I created a certificate for cdn.example.com, chose custom and entered cdn.example.com for use with HTTPS.
I created a CNAME in my DNS configuration for cdn.example.com, and I added the validation record as requested by AWS. The certificate shows up as issued and validated.
Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “cdn.example.com”, which could put your confidential information at risk.
No images get loaded and the site does not render as it should. If I use the cloudfront url (i.e. d12345.cloudfront.net), all works fine. Do I need to add a SAN to my certificate, such as the main domain (i.e. example.com) in addition to cdn.example.com? If so, how does that work as I already use a SSL certificate for my www.example.com and example.com from Let's Encrypt.
I am using WordPress and wpfastestcache to integrate CloudFront with the website, where I specified cdn.example.com and the origin as example.com.
This question was confusing, since it seemed to describe a very unlikely condition. How could a newly-configured CloudFront distribution with a new certificate from ACM offer an invalid certificate?
In truth, I was distracted by part of the "helpful" browser error message, "You might be connecting to a server that is pretending to be..." I mistakenly assumed that this implied that the hostname in the certificate was correct ("pretending to be") but that the certificate was invalid for some other reason.
As it turns out, the certificate being offered was the default, generic *.cloudfront.net certificate, so the hostname in the cert didn't match the custom domain name.
After creating a certificate in ACM, it needs to be associated with the CloudFront distribution, as mentioned at https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesSSLCertificate.
Another hint to the nature of the problem would have been observable in the ACM console. There, the certificate would have shown In Use? No.
In Use? – Whether the ACM Certificate is actively associated with an AWS service such as Elastic Load Balancing or CloudFront. The value can be No or Yes.
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-list.html#gs-acm-list-console
I have a multi-domain environment (active directory forest), e.g. subdomain1.mydomain.com, subdomain2.mydomain.com where mydomain.com is root AD domain (GC) and subdomain1 and subdomain2 are child domains under mydomain.com. In total I have four subdomains and more can be added if required.
I have web servers like server1.subdomain1.mydomain.com and server2.subdomain2.mydomain.com. I need to get an SSL certificate to secure these server and also any servers which are added in future.
My questions are:
Can I have a multi-level wildcard certificate (*.*.mydomain.com)
to secure all servers?
Do I need to have individual certificates for
each subdomains (e.g. *.subdomain1.mydomain.com,
*.subdomain2.mydomain.com)?
Is UCC certificate suitable for this requirement?
Thanks.
Can I have a multi-level wildcard certificate (..mydomain.com) to secure all servers?
No, multi-level wildcards will not be accepted by the browsers.
Do I need to have individual certificates for each subdomains (e.g. *.subdomain1.mydomain.com, *.subdomain2.mydomain.com)?
There is no need to have individual certificates. You can have a single certificate which covers multiple hosts
Is UCC certificate suitable for this requirement?
Probably yes.
I would like to generate an SSL Certificate Signing Request (CSR) for the procurement and installation of an SSL certificate.
My question surrounds what we should enter for the FQDN given our specific situation
We will be hosting a domain name 'www.foo.com' within our server.
This domain will be accessed via a different domain 'www.bar.com' which will be CNAMEd to our hosted domain 'www.foo.com'
We want the client to see that the domain 'www.bar.com' has a valid SSL certificate.
So my question is, when we generate the CSR do we need to enter 'www.foo.com.' or 'www.bar.com.' as the FQDN for hostname in the CSR?
Edit: It is not intended that the domain name www.foo.com will ever be used to access the website.
Looking at this answer https://serverfault.com/questions/494654/which-fqdn-hostname-to-use-for-ssl-certificate-signing-request-when-using-a-cna it looks like in our CSR we should be using 'www.bar.com.' but confirmation from a suitably qualified person would be appreciated!
www.bar.com
Whatever FQDN the client requests in the browser should be in the subject of the certificate - no matter what happens in "the background", be that in terms of DNS resolution, backend proxying etc.
As long as the browser thinks it's talking to www.bar.com, the browser will also expect www.bar.com to be in the certificate