Same wildcard SSL certificate with different organizations - ssl

I'm working in a company that has recently bought daughter company. Migration procedures are happening and I was asked this:
We already have purchased a wildcard SSL certificate on let's say *.someurl.com and in CSR we entered our current company's name.
Now someone who is responsible for migration came to me and asked to get a new wildcard certificate for the same URL (*.someurl.com) but in CSR there should be the company's name that we recently bought and they should work parallel to each other.
I can't find any info on this on google, so I'm asking here. Is it possible to do so?
For CA, we're using thawte.
Thanks!

There is no problem to create a new certificate for the same domain but with a different organization. Of course, you still need to prove that you actual own the domain the certificate is for but this should not be a problem in your case.
What is not possible is to just modify the certificate or the CSR because this would invalidate the signature. Instead a new CSR with the new information need to be created and be submitted to the CA for signing. The private key from the previous certificate could in theory be reused. But unless there is public key pinning done against this certificate I see no advantage in this.

Related

Why does SSL architecture have two distinct functions?

On a high level, it seems to me that SSL has two distinct functions:
To bind a domain name to a specific organization
To send out a public key for encryption
These functions seem very different to me. What is missing from my understanding of the model?
Update for clarity: I base my question on findings from searches. For example, one source says, “SSL Certificates bind together: A domain name, server name or hostname. An organizational identity (i.e. company name) and location.” And, other sources discuss encryption.
SSL has none of the functions to describe. What you describe are only parts of how the actual functionality is achieved. The real function of SSL is to protect the data in transit.
The certificate with subject and key is needed within this function (at least) to authenticate the server in order to make sure that the client talks to the expected server and not to some man in the middle. This is achieved by making sure that a) the certificate is issued by a trusted party (the certificate authority) and that it is issued to the expected domain, i.e. the same one which is included in the visited URL.
Note that SSL does not make any claims about how trustworthy the site or the party behind the certificate is. It also does not make any claims if the organization you expect is really the one which owns the visited domain. The latter part is done by the certificate authority for some kind of certificates, i.e. the EV certificates. But for most certificates it is only checked that the current owner of the domain requested the certificate and not who the owner actually is.

youtube-v3-api security certificate renewal

We are required to add certificate for https://www.googleapis.com/youtube/v3/videos to our trusted certificates on our servers for complying with security policies.
We noticed that the certificate expires on the 24th of November,2016. Can someone help with a support team mailing list which we can contact to get the new certificate in advance so that there is no outage for the functionality.
Thanks
I think you are missing a basic concept of TLS: the role of a certificate issuer.
You usually don't lock yourself to a specific certificate for a site and hope that somebody will provide you with the new certificate up front if the old certificate expires and that you then can change all your clients to accept this new certificate. This simply would not scale.
Instead you trust an issuer (CA - certificate agency) to issue a certificate for a specific site. Then you check for any certificate you got that the trust chain to your locally trusted certificate is fine and that the subject of the certificate matches the site you access. The same CA certificate (or at least the public key inside) will be used for many years to issue new certificates, contrary to leaf certificates which are only valid for 1..3 years or even a few month only to reduce the risk of compromise.
In summary: Don't expect anybody to tell you up front when they issue a new certificate because nobody will tell you. Instead do it like everybody else and trust a CA.
TL;DR: you can't. Validate the certificate using CA list.
Google already use a pinning mechanism in chrome:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
But www.googleapi.com is not pinned in that list (only translate.googleapis.com), it means google didn't ensure anything about his keys/certificate/certificate chain. So you can't pin it without taking the risk to break something, even before the renewal: they could change the certificate and/or the chain without notice.

Multiple SSL certificate on one domain

We use nginx for SSL termination and rotate ssl certificate yearly. But whenever we rotate we send notification to user about date and time when we are going to apply the change and they have to make changes on their end at same time. There are few enterprise tools which few customers use, and they need same certificate loaded in their trust store.
So I wanted to check if there is any way to deploy two certificates on one domain temporarily like for a week. For that period both the certificate works, so customers can move to newer certificate over that period. May be some kind of certificate chaining or something which can help us solve this problem.
PS: I am sorry if sounds too stupid, just want to listen others view on this problem.
Thanks,
GG
While it would be possible to send any number of certificates to the peer (that's what you do when sending intermediate certs) it is expected that the certificate matching the hostname is the first and the following are the chain certificates in proper order. A client will not just look into all the certificates and pick the ones which look best.
But it should be possible that you give the client the new certificate in advance and it can add this one to the list of trusted certificates, without replacing the old one. And as long as you serve the old certificate the client will find this as trusted, once you move over to the new one the client will find this as trusted too.
Even better might be to use your own CA to issue all the certificates. Then the client needs only once to install this CA as trusted and then it will automatically trust any new certificates issued by this CA, no matter if you rotate yearly or daily. This is how it works in the browsers, where google or whatever does not need to ship the new certificates to all browsers but instead these are signed by a CA trusted by the browser.
The certificate is binded exactly to the FQDN which the Users type on the address bar. If you procure a Public SSL certificates from the likes of Symantec , Digicert, Thawte, etc your clients need not update their certificate store reason being the Public Certificate Authority (CA) roots & intermediate certificates are well known and are very much a part of all the Leading OS certificate stores.

Can I purchase only one certificate and use it to sign/protect many resources?

I have done some research and I learned that both PFX files and SSL certificates are X.509 certificates. Then I wondered: can I purchase only one certificate (PFX/SSL/CER) and use it for many purposes? I need to do the following:
Allow HTTPS/SSL on my website (very important)
Sign PDF documents (very important)
Sign EXE/MSI files (important)
Sign e-mail messages (optional)
Do I need to purchase one certificate for each purpose? Or can I use only one certificate?
Thanks
SSL certs and Code Signing certs are different animals and can't be used interchangeably. One certifies a publisher and one certifies a fully qualified domain name.

Create my own intermediate cetification authority from commonly trusted certificate

I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world

Resources