Hi, I want to inquire about SIP handler - SIP terminal support for TLS encryption.
It requires server certificate and root CA certificate. Which are to be installed on telephony server and SIP handler controlled SIP terminal respectively.
Would I be able to generate these using Let’s Encrypt?
Hope to get some help. Not really that familiar with certifications.
Thank you
You can get a server certificate from Let’s Encrypt, but not your own root certificate. Fortunately, you almost certainly don’t need your own root certificate. Typically when software asks for a root certificate, it wants a copy of someone else’s root certificate, like DST Root X3 (as listed at https://letsencrypt.org/certificates/).
However, Let’s Encrypt might be more complicated than you need. Since you are setting up both the telephony server and SIP handler, most likely you can generate your own root certificate and then generate your own server certificates from it. Here’s a simple tool that can help you with that: https://github.com/jsha/minica.
Hi jsha,
Thank you for replying. Sorry, not really that familiar. I guess I really have to do a lot of reading.
I attached the PDF of the plan we want to use it for.
Hope that would help.
Thank you once again.
Digital certificates are small documents that state that a particular encryption key is valid to use with a particular Internet domain name or other kinds of identifier. Their main benefit is preventing against a man-in-the-middle attack
which, in the absence of certificate validation, could easily be performed by any network operator or sometimes by people who can hack a DNS server or network router. The effect of the man-in-the-middle attack would be to remove the benefits of encryption for secrecy and authentication of the data that gets sent over the encrypted connection.
The certificates issued by Let’s Encrypt can be used to protect any kind of connection that uses the TLS protocol. Most often this is HTTPS for a secure web site, but it can potentially be lots of other different kinds of Internet protocols (including SIP).
The certificates that Let’s Encrypt issues are called end-entity or leaf certificates because they refer to the actual entities like Internet servers that are going to use the certificate to protect connections. The certificates are issued by a certificate authority that is itself described by a certificate, referred to as an issuer certificate, intermediate certificate, or chain certificate. The intermediate certificate is issued by a trusted root certificate authority which is described by a root certificate. Software making a TLS connection will need to have a set of certificate authorities that it trusts and then it can validate certificates that it receives to see whether they were issued by authorities that are part of the client software’s set of trusted roots.
The advantage of using a publicly-trusted CA like Let’s Encrypt is that our certificates can be trusted by a very broad variety of devices and software because our own root certificate (in some cases) and another root called IdenTrust that has given us an intermediate certificate (in most cases) are already included in the trusted root sets for lots of mainstream devices and software. And we follow industry rules and audit procedures aimed at allowing us to issue certificates that can be trusted by the general public.
If you have a closed environment where you control the devices, you don’t necessarily need a publicly trusted certificate because you can issue your own certificates and then tell your devices that those certificates are valid (you know that they’re valid because you create them yourself!). There are various ways to do this and the best choice depends on the nature of your environment, including the number of client and server machines and how many different people operate them.
If you do choose to use Let’s Encrypt, you need to make visible changes of some sort in order to prove to the certificate authority that you really control the domain names that you’ve requested your certificate to cover.
Then your Let’s Encrypt software will obtain a certificate, which you can then install in your service (although the certificate is only valid for 90 days so it’s very valuable to script a way to renew it automatically). Clients connecting to it probably already accept the IdenTrust root so if you serve the intermediate certificate that we give you together with your end-entity certificate, the clients will probably already accept the certificate as valid. If you control the client, you can also specify our intermediate as a trusted issuer certificate to ensure that the client accepts it.
Hi Schoen,
Thank you so much for this helpful information.
Currently reading about it and referencing the link you sent.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.