1

I am using Ubuntu which has self-signed certificate (not done by me) which expired few weeks ago (this machine is used locally only). I tried using openssl verify cert.pem but without the .pem files I can’d do anything. I look up in /etc/ssl/certs/ but inside that directory there are thousands of .pem files.

The output of curl --verbose https://domain.net is the following:

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56 STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs

I went to /etc/ssl/certs/ and tried openssl x509 -noout -serial -fingerprint -sha1 -inform dem -in ca-certificates.crt but then I get “Error opening Certificate ca-certificates.crt”

Where do I begun to troubleshoot the problem so I can renew the certificate?

Edit: I located the old .key file and created a new certificate, edited the apache ssl config file so it uses the new certificate (and the old key). All looks fine now. Thanks all!

6 Spice ups
2

You need to first figure out which the actual certificate is that the web server is sending to clients. Best way to do that is inspect your web server configuration file.

Are you using Apache? Nginx? Some other web app?

Apache files would be in /etc/apache2/sites-enabled

Nginx /etc/nginx/sites-enabled

(the files in sites-enabled are actually symlinks to …/sites-available but the ones in “enabled” are the ones actively in use so that will be your authoritative list).

In the config files look for lines like SSLCertificateFile (the Apache version) or similar when dealing with other programs.

More details would be helpful at this point to help narrow down your search.

3

Hello Gerrard,

Thank you for the reply.

I located both the .pem and .key files under /etc/apache2/ssl

What will be the next step?

4

Next step is to replace the certificate file you have located with a new version. You could renew the one you have but it will depend in part in how it was generated in the first place and trying to figure that out may take more time than is worth. As this is self-signed stuff it’s just as easy to just create a new set of files from scratch.

There exist many good tutorials on how to do this. Here is one of many such examples:

You can skip the firewall related parts as that doesn’t apply to you. Just focus on the certificate and key generation part.

5

Thank you, is there a danger that the new certificate could create problems with clients? I have SVN installed on that server (main reason it exist) will the SVN clients have issues with that?

6

I don’t see an actual issue. If needed, you can configure such SVN and other version control clients to ignore the SSL certificate if needed (which you may be doing already as it won’t trust a self-signed certificate out of the box).

A new cert is not going to cause more, or fewer, problems than the one you have (other than the fact that your current expired one is causing more issues already).

7

Sounds great! Is there a way for me to find how the previous cert was created, just of curiosity?

8

A generated certificate does not contain the commands that were originally run to create it. If the certificates were created on that server you might find “openssl” commands in your shell’s history. You would need to know the user account that was used.

history | grep openssl

You could run that as ‘root’ which might be the account that was used. Just a guess.

1 Spice up
9

Looks like either the previous cert was not created using openssl or I’m not digging inside enough. The output of

history | grep openssl

shows only the last few commands I tried. I also tried just history but I don’t get the full command history, only 2/3 of it.

10

Could’ve been created on another computer and uploaded to the server. Maybe on a different user account belonging to the previous person. Shell history has a limit as well. It doesn’t retain unlimited entities.

It’s not a reliable way to reconstruct something that happened 1 or more years ago. It was just a shot in the dark.

11

I think, but I’m not sure, that history might be associated with the tty, as well as the user.

So if you were root on pts/2, the history might not include root’s commands on pts/0, pts/1, pts/3, tty01, etc.

Also, sudo will log commands it is asked to run, but by default, I don’t think it logs after invoking a shell. Eg, " sudo su - " will be logged by sudo, but subsequent commands after the new login environment will not be logged by sudo. But those commands should by accessible via “history”.

Try

last  |  grep  root  #to see login by root

last  |  grep  root  | sort -k2  #to see root logins by tty

Then get root on those ttys and see if you can find more history that includes openssl

If it’s helpful, you might also want to include date and time in your history output:

HISTTIMEFORMAT="%d/%m/%y %T "
12

Hello pigdog,

Thanks for the reply but both of these commands don’t return anything and I’m running them as a sudo. Am I doing something wrong?

13

“last” should list a history of users’ logins, time, tty, pseudo-tty, host (if over the network).

Try it without arguments or piping. It gets its data from /var/log/wtmp (or maybe whatever local directory has your logs).

E.g.

$ last
root     tty3                          Sat Mar 14 10:04 - 10:07  (00:03)    
dan      pts/1        :0               Sat Mar 14 09:56   still logged in   
dan      pts/2        :0               Thu Feb 20 15:34   still logged in   
dan      pts/6        :0               Sun Feb  9 13:11   still logged in   
....
14

Bash history is not specific to the device used, but if signed on in multiple places you may not get all the history recorded.

It’s just a text file (like everything else in Linux) - check it out at ~/.bash_history

1 Spice up
15

Thank you so much! I found the commands used (and on which files were used), so now I just have to… repeat the procedure?

1 Spice up