IPFire WebGUI SSL Certificate Files

Security
1

Hi all -

I’m in the process of adding my own certificates to the IPFire Apache configuration to get rid of browser warnings. I have created my own CA for that purpose and added the certificate to my browser / host configuriation. This is working well with all of my internal servers.

My question is: Why does /etc/httpd/conf/vhosts.d/ipfire-interface-ssl.conf show redundant lines regarding the SSL certificates? I’m referring to the last 4 lines in this block of text:

SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite AESGCM+EECDH:CHACHA20+EECDH:@STRENGTH:+aRSA
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
SSLCertificateFile /etc/httpd/server.crt
SSLCertificateKeyFile /etc/httpd/server.key
SSLCertificateFile /etc/httpd/server-ecdsa.crt
SSLCertificateKeyFile /etc/httpd/server-ecdsa.key

Isn’t it sufficient to have only one certificate and one key file instead of two named “ecsda”?

Thanks!

2

Hi,

if you read those four lines more closely, you might have seen their file paths differ.
The first one points to a RSA key pair, while the latter refers to an ECDSA key pair.

Quoted from the Apache httpd documentation for SSLCertificateFile:

The directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication - typically RSA, DSA, and ECC.

Modern browsers will support ECDSA, thus establishing a TLS session faster and with less network traffic. In order to be compatible to clients without support for elliptic curves, we are currently generating an RSA key pair as well, but this might be dropped in a future release of IPFire.

Thanks, and best regards,
Peter Müller

3 Likes
3

Thanks for your reply! I have indeed noticed the differences in file names, but since they were prefixed by the same directive, I was puzzled whether this was redundant or not. Other hosts in my network only have one *.crt and one *.key file.

So if I were to create these *-ecda.crt and *-ecdsa.key files with OpenSSL, how would I create the ECDSA certificates?

Thanks,
datamorgana

4

Hi,
you can take a look at this IPFire script to see how the certificates are generated:

4 Likes
5

Cool, that helps! Many thanks!
With my own CA_Root key I successfully created these files as:

$ openssl ecparam -genkey -name secp384r1 -out server-ecdsa.key
$ openssl req -new -key server-ecdsa.key -out server-ecdsa.csr
$ openssl x509 -req -days 999999 -sha256 -in server-ecdsa.csr \
    -CA ca-root.pem -CAkey ca-root.key -CAcreateserial \
    -out server-ecdsa.crt -sha256 -extfile server.ext
1 Like
6

Hi,

Apologies if this is seen as cross posting and maybe suitable to a new post.
Would using https://letsencrypt.org/ not be a sensible idea for secure boxes.
The certs can be scripted to update every 90 days.
It would sort out the issue of self signing.

If of interest I could look to perhaps generate a patch for it.

Thanks
Joe.

7

What is the problem with a self-signed certificate?

1 Like
8

What would you try to achieve by that,@jjdoran ? Making the IPFire publicly accessble via port 80 and 443? That’s what you need to get Letsencrypt to work. For maintenance purposes only done by yourself, you don’t need a Letsencrypt certificate. Any self-signed cerificate will do, if you need access from within your green or blue network. For access to the firewall from the Internet I would prefer an OpenVPN connection, also with self-signed certificates that I trust.

9

Nothing specifically an issue with self signing, just that it opens a man in the middle attack possibility if the attacker manages to get hold of the private key. Albeit if you set up your own CA you can secure the private key very well. You could also bind the cert to allow only access from that client. By using letsencrypt or another vendor you are hoping they protect their private keys very well and thus stopping the man in the middle getting to decrypt your inflight data. Most users will blindly click on exception in the browser. Is it original cert or one that’s been replaced or injected by an intruder etc…

10

The private key is stored on the IPFire machine. If an attacker can get this far, the system is already compromised beyond repair.

3 Likes
11

True if its the private key on the IPfire machine and they have remote access. You’re hosed anyhow. However If one can intercept your connection and present you with a self signed cert you have no way of knowing its them that you are talking to.

12

This is incorrect. You would have a look at the certificate the first time, then import it into your browser if someone then tampers with your network, you will notice it.

If you simply click “accept” as soon as you see a certificate warning, then the hacker will have won.

1 Like
13

Not all users use the same browser/device session to access systems. You are therefore presented with a self signed cert each time and have to verify. As someone already pointed out, in an ideal world you would import a client cert and bind it the device for pure control.
I think we are going a bit off topic now. I will leave it there. We could debate this one for a long time. :slight_smile:

2 Likes
14

got an error with latest line:
[root@ipfire httpd]# openssl x509 -req -days 999999 -sha256 -in server-ecdsa.csr -CA ca-root.pem -CAkey ca-root.key -CAcreateserial -out server-ecdsa.crt -sha256 -extfile server.ext
Can’t open server.ext for reading, No such file or directory
126534734345536:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:69:fopen(‘server.ext’,‘r’)
126534734345536:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:76:

15

No such file or directory:crypto/bio/bss_file.c:69:fopen(‘server.ext’,‘r’)

You have to create this extension file yourself in advance with some extra information about the host etc. It will be taken as input. Example:

$ cat server.ext

basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myhost.mydomain.org
IP.1 = 192.168.1.99
16

thank you for reply i created server.ext using your suggestions

bsicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = ipfire.localdomain
IP.1 = 10.0.0.1

now getting error

Can’t open ca-root.pem for reading

17

You need to create the root key pair first, thus establishing your own, private certificate authority.

There are lots of tutorials out there, e.g. here
https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html and here
https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/

In my example above I have used some obvious looking names as file names. I have put my CA-Root certificate in PEM format in the file “ca-root.pem”, my private key in “ca-root.key” and used both for signing the server certificate signature request.

18

That is only required if you use the HTTP challenge to get the certificates.
But there is also an DNS challenge which doesn’t require publicly accessible ports. :slight_smile: