My operating system is (include version):
CentOS 5
I didn’t produce certificate yet so didn’t fill infos/ My question is : can I have multiple certificate for only one domain name ?
For example, for mysite.com, I’d provide service1 and service2 and I would like to have different certificates for these services but for the same domain name. Is it possible (can I specify different Common Name in certificate command creation ?) ? Or I must Have different domain name like mysite.com/service1 and mysite.com/service2 ?
Thanks a lot !
Once you have the certificate, you can simply copy it - so you can use it on multiple services ( I assume you mean services like mail, SFTP as well as https )
No, it’s more webservices. Oh sorry, I forgot to say I’d want different certificates in the sense that a user with certificate1 for service1 will have secured connection but won’t have for service2 because service2 is associated to certificate2. Cert1 and 2 are diffrent but for the same domain name. Is it possible ?
I'm not understanding fully ( that may be me though )
If someone is going to https://yourdomain why are they going to 2 different places / services ? you have a load balancing server or something ? (in which case, yes it's perfectly possible, although personally I'd put the same cert on both). Why do you want different certificates on the different "services" ? rather than the same certificate - if it's for exactly the same domain name ?
when you say
Why does the user have the certificate ? The service would generally have the certificate, unless you are talking about key pairs ( as used in VPN services )
Oh sorry, I'm totally confusing about all that, I discovered certificates few times ago and I take charge of university research project (and I'm spanish so sorry for mistakes or trouble explications). "Client" wants different certificates for different services (I neither understand why for the moment)
Different services are reachable through REST, so through differents path (mysite.com/service1) or through differents port in such way that clients' requests are well redirected to the adapted services, so they don't ask exatcly the same path (https://mydomain:1234, https://mydomain/oneservice, ...)
--> Yes Service has, forgive me, here is my confusion (and user have adapted CA's public key for identifying server if I well understood)
Thanks, I think I understand a little better (although not fully)
You could have 2 different certificates for the same domain name, yes. I can’t say if it will fully work for your scenario though, as I don’t fully understand it.
Me neither sorry.
So how do you think I can do it?
Can I specify different Common Names during certificate creation to distinguish them or am I obliged to create for https://mydomain/service1, https://mydomain/service2, …
Thank you again for your help.
You can only create for “mydomain” (or a subdomain such as “subdomain.mydomain”) you can’t create a certificate specifically for a folder or directory.
Since what you are asking is a little unusual (if I understand it correctly), I don’t think there is an easy way to do it with certbot (the official client ). It would be possible with certbot easily if you were prepared to use subdomains as well on the certificates ( service1.mydomain and service2.mydomain) as you could place the subdomain in the Common Name, and include mydomain in the SANS.
without using subdomains, I think you would need to use one of the alternate clients - exactly which one would be best, and how to set it up would be dependent on your system - which I don’t know / understand enough about.
Trusted public CAs like Let’s Encrypt are only allowed to write Fully Qualified Domain Names (or IP addresses) as Common Names for TLS certificates. It is not possible to specify something else.
But I think you will run into other problems sooner. The modern Web uses a technique called Server Name Indication, SNI, to have clients tell a web server what name they expect to connect to, and thus which certificate they expect, but the clients don’t provide any other details, just the name, so you can’t choose a different certificate for any reason other than the Host name of the web server the client is connecting to.
Are you sure your research project isn’t looking for client certificates rather than server ones? Both sides in a TLS connection may have a certificate. On the public web usually we don’t have client certificates, just server ones. But instead of clumsy usernames + passwords, it is possible to use a client certificate to prove your identity, and this is especially useful for web services, as opposed to systems used by humans directly.
Let’s Encrypt doesn’t specifically offer client certificates, although its certs can be used that way in a pinch. However you can make your own certificates, just for one particular service, which will often be suitable. You should look for documentation about making and managing your own client TLS certificates, perhaps with the openssl command line tools. Going into much depth is really beyond the purpose of this discussion site.
The private key does not expire, no.
The by "Public key (cert.pem)" I assume you mean the certificate, which does expire, yes.
This depends on your service (apache, nginx, something else ?). Without that information I can't say which you need. Generally you will need either the cert and chain or the full chain.
Public and private keys go together as a pair, you can't generate one without the other.
The certificate, which is in cert.pem, expires. A certificate is an (electronic) document, signed in this case by Let's Encrypt, and the expiry date is part of that signed document. Your public key is listed in that document and the associated private key is in privkey.pem. The keys themselves don't expire, you are welcome to ask for a new certificate with the same public key (and thus, the same private key since they're a pair) but you should consider replacing keys periodically because this is more secure.
A server should send the entire "chain" of certificates, which is in fullchain.pem, but some servers will need to be configured with your certificate (cert.pem) and the chain of other (intermediate) certificates (chain.pem) separately, rather than all altogether as a single file, that's why certbot generates the three separate files.
If only your end entity certificate is sent, some client software will obtain the others needed using AIA information, some will use a cache (so it works if they've recently seen a similar chain but not always) but you can't rely on these, so you are required by the TLS protocol specification to send all of the chain.
OK, this is apache < 2.4 so I have to use chain.pem in configuration (with conversion pem to crt or not obliged). Ok, so there is no specific file for public key, public key is included into certificate cert.pem.
Thank you very much again for explanations, this is so much more clear now.
)
sorry.