Differences

This shows you the differences between two versions of the page.

--- software:openssl:internalca:start [2025/10/25 03:18] – created rodolico
+++ software:openssl:internalca:start [2025/10/25 03:28] (current) – rodolico
@@ Line 1: / Line 1: @@
 ====== Internal Services SSL Certs ======
-Public SSL Certificates are not easily available for private networks. Since the public services are giving you verification that the site the users are using is the site they think it is, the provider of the certificates must be able to verify the information before issuing the certificates. This is generally done by having a small file placed on a web server, or a DNS entry made; things which can only be done by an authorized administrator of a domain.
+<WRAP center round important 60%>
+The procedures described here are generally used for local networks. In only limited cases would this be useful for any public service. For example, you would not use this to secure your public web/mail/ftp site. This is only used for internal, LAN based services which have no public access.
+</WRAP>
-For private (internal) networks with no access to public IP addresses, it is actually fairly simple to create your own, internal, Certificate of Authority (CA), deploy that to your workstations, then sign certificates for internal web sites, mail servers, ftp sites, etc... with that CA. You can even use this to sign certificates for your internal network switches and routers so you don't have to constantly put up with the "Certificate Invalid" notice when you go to them.
+Most SSL Certificates are used on public facing devices and are provided by large organizations which specialize in this. For example, this web site uses an SSL certificate provided by [[https://letsencrypt.org/Let's Encrypt]], an organization the provides free SSL Certificates and is supported by [[https://letsencrypt.org/donate/|donations]].
+In many cases it is useful to have SSL certificates in your Local Area Network (LAN), and these can not readily be provided by the public SSL organizations. They are designed for situations where you can prove ownership of a publicly visible service, like a web site or mail server.
+There are a few companies which provide a service for internal networks, but the cost generally exceeds what most businesses are willing to spend, and as an alternative, it is easy to simply create your own Certificate of Authority (CA), add the generated certificate to all of your internal computers, and use that CA to generate certificates for your internal services.
+We will use openssl to generate the CA's and Server Certificates. The following articles walk you through doing this. Since, at [[https://dailydata.net/|Daily Data]] we use this for some of our clients and for ourselves, we have created a set of script that will make the process simpler. These scripts are written in Perl and released under the FreeBSD license. They can be viewed in our [[http://svn.dailydata.net/listing.php?repname=sysadmin_scripts&path=%2Ftrunk%2Fssl_certs%2F&#aafc6978bf0bfea4e233f744203faa0f5|Subversion repository]] or checked out with the following command.
+<code bash>svn co http://svn.dailydata.net/svn/sysadmin_scripts/trunk/ssl_certs</code>
+**Note**: openssl has a built in command, ca, which was written as a sample minimal CA application. I chose not to use that since our needs (a dozen services, at most) and due to the warnings at the bottom of the man page (man 1 openssl-ca).
+I have attempted to create a system which uses the recommended steps for such a small setup as of Fall 2025. You may find other articles saying to do things a different way. For example, an RSA private key can be created with any of these commands:
+  * openssl genrsa
+  * openssl req (with the -newkey parameter)
+  * openssl genpkey
+I chose to go with //openssl genpkey// as that is the recommended way as of this date. But, be aware, there are multiple ways to achieve the result using openssl.
 Start with [[software:openssl:internalca:overview|]], to get an idea of what is going on.