Trying to create a certificate for a RHEL internal server

Server
#1

I have been tasked with trying to install an SSL certificate for an internal Linux server that we have here in our office. It is hosting two Atlassian products; Jira and Confluence and I am trying to get them setup with an SSL certificate. We had this working on another server but it died and the developer that helped me with this no longer works here. I am not a programmer or a developer. My background is in hardware; I just took this position after being laid off from my previous position of over 25 years. The name of this server is “cowboy” (named by my boss) and when I try to run the “./certbot-auto certonly --webroot” command I get an error of “An unexpected error occurred:
The request message was malformed :: Error creating new authz :: DNS name does not have enough labels”. I think the problem is the name of the server and I have tried changing it to a different name when I was trying to get a valid certificate using the keytool commands so I thought maybe it would work better trying Let’s Encrypt. I am a novice at this so any help would be greatly appreciated.
Thanks,

#2

Let’s Encrypt is a public CA trusted for the Web PKI. Such CAs are prohibited from issuing certificates for DNS names that can’t exist in the public Internet like “myprinter” or “jiraserver”. They are only allowed to issue for Fully Qualified Domain Names like jiraserver.example.com.

Beyond this rule, Let’s Encrypt further requires that you (or a program like Certbot on your behalf) prove control over the exact name requested. Three methods of doing this are permitted, but all will need you to at least be able to make the machine’s name part of the Internet public DNS.

1 Like
#3

OK I will try a different name again.
Thanks,

#4

When you had this working on another server, was it using Let’s Encrypt? Then the server probably had a publicly facing name as well as its internal name. You should make sure the current server has a publicly facing name too, like “cowboy.internal.example.com” (replace example.com with your company’s domain name).

If you want to use the webroot method (probably the easiest for your situation), you’ll also need to make sure your firewall allows access from the Internet to port 80 on “cowboy.internal.example.com”. If you don’t want to open up your firewall like that, you can use the DNS challenge. This will be more complicated, but we can provide you some resources if you want to go that route (we’d need to know what DNS server software your company uses).

1 Like
#5

No on the other server we used the keytool commands to create all the ssl files, keystore, and submitted the CSR to Cacert.org. I have tried doing it that way on this server over and over but keep running into the issue where a web browser keeps telling me that the certificate is not valid and I have to setup a security exception in order to get to the product’s login page.

#6

That’s interesting, because CACert.org has never been trusted by default in browsers, so the old server would have had the same “certificate not valid” problem. I’m guessing everyone had already set up security exceptions for it, so it seemed to just work. Alternately, it’s possible but unlikely that everyone at your company manually installed CACert.org’s trust root on their computers.

That means that by getting a publicly trusted Let’s Encrypt certificate you’ll be going above and beyond what was in place before. So don’t feel too bad if it’s hard, and make sure you get credit for the improvement. :slight_smile:

2 Likes
#7

Things being setup before on that other server could definitely have been this case as it was here when I started at this position about 5.5 years ago. Ours is a very small office; only 4 of us here, including my boss. I doubt if anyone had installed the Cacert.org trust root on their computers as there were only 7 of us working back when we setup the SSL on that server and 2 of those worked full-time at one of our client sites. I had never even heard of Jira or Confluence or Atlassian for that matter before I took this position so anything and everything that I know about editing server.xml files, etc I have had to Google and learm OJT. I do have the secure ports already opened up on our firewall so we can access Jira and Confluence from outside our office.

#8

I just tried changing the name of the server to cowboy.internal.lsgsolutions.com and ran the cert command again and got this error-
1: Enter a new webroot

Press 1 [enter] to confirm the selection (press ‘c’ to cancel): 1
Input the webroot for cowboy.internal.lsgsolutions.com: (Enter ‘c’ to cancel): /var/www/manual
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. cowboy.internal.lsgsolutions.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for cowboy.internal.lsgsolutions.com

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cowboy.internal.lsgsolutions.com
    Type: connection
    Detail: DNS problem: NXDOMAIN looking up A for
    cowboy.internal.lsgsolutions.com

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

#9

The address must also be publicly resolveable. Have you created the relevant entry in your DNS zone? Note that for webroot, the server also must be accessible at this address over port 80 from the public internet.

#10

Is there info somewhere on how to do this?

#11

It depends on what your DNS setup is and what DNS server you are using. Can you provide more info on that?

Also FYI, when you reply by email, your email signature (including your office phone number and some logos) gets posted publicly on the forum. I edited your post to remove them but keep that in mind. Maybe if you’re posting by email make sure to delete your signature first.

#12

I think that is maybe the problem, as this server is not a webserver. It is just a server that I installed Oracle Linux ver. 6 on to try to setup Jira and Confluence on it.

#13

You may need to install a web server (like Apache or Nginx) on this server at some point, but the immediate problem is this:

NXDOMAIN is DNS-speak for “domain not found.” That means that when Let’s Encrypt tried to look up your domain in DNS, it didn’t find it. You can test this for yourself: Try to visit cowboy.internal.lsgsolutions.com from somewhere outside your office network (for instance on your phone with WiFi turned off). You’ll get a DNS error. You need to configure your DNS for cowboy.internal.lsgsolutions.com to point at your server, and you’ll need to ensure your server is reachable from the public Internet, before you can get a certificate.

#14

Well actually I can’t get to that server even from my laptop right here in the office, which is on the same LAN. What I mean is I get the DNS error even clicking on that server name or pasting it into a web browser.

#15

OK today I tried to setup apache on this server but when I try to start it I get the following error-
[root@cowboy ~]# /etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: httpd: apr_sockaddr_info_get() failed for cowboy.lsgsolutions.com
httpd: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName
(98)Address already in use: make_sock: could not bind to address [::]:8443
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:8443
no listening sockets available, shutting down
Unable to open logs

I then ran the following-
[root@cowboy ~]# netstat -anp | grep :8443
tcp 0 0 :::8443 :::* LISTEN 30730/java

Port 8443 is the secure port that I have configured for Confluence to run on.

#16

It sounds like Apache is also configured to listen on port 8443, so there’s a conflict. If you can find the places in your Apache config where it is set to listen on port 8443 and remove them, you should be good.

#17

Only one thing can listen on a port at a time - you’ll need to set this up to use a different port, or stop anything else listening briefly and then restart it again when you’re done.

#18

OK so now I am even more confused because I am trying to start apache. So how can it be using port 8443. I haven’t done any configuring of apache, I am just trying to get it to start. If that was the case shouldn’t port 8443 have shown up in 2 places when I ran the previous command?

#19

Or is it because I configured port 8443 for the secure port for Confluence, because that is my ultimate goal, of course is to have Jira and Confluence running on ports 8444 and 8443 respectively and have a valid ssl certificate in place for them on this server. I know that jira and confluence run in Tomcat so maybe that’s why it’s showing using port 8443 already

#20

When I looked at the httpd.conf file it only shows that it is listening on port 80.