Apr 04 2024

OpenSSL 3 Dovecot error Failed to initialize SSL server context – dh key too small

Recently on one of my personal servers, I upgraded OpenSSL to 3.2.1 and everything seemed to go smoothly. However, I then noticed that though my Postfix MTA (Mail Transfer Agent) seemed to be working, I didn’t get any updates in my email client. That, to me, indicated a problem with my Dovecot MDA (Mail Delivery Agent).

Looking through the logs, I noticed the following error message repeated regularly:

Apr 04 01:50:55 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<l+Y27D4VaM2s3ZZS>
Apr 04 01:50:55 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<Hf827D4Vcs2s3ZZS>
Apr 04 01:50:57 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<HzBb7D4VfM2s3ZZS>
Apr 04 01:50:57 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<UElb7D4ViM2s3ZZS>
Apr 04 01:50:58 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<zilq7D4ViuOs3ZZS>
Apr 04 01:50:58 [dovecot] imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting): error:0A00018A:SSL routines::dh key too small: user=<>, rip=REMOVED, lip=REMOVED, session=<3EJq7D4VhOOs3ZZS>

The main error message is Failed to initialize SSL server context: Can't load DH parameters (ssl_dh setting) and the specific cause of the failure is dh key too small. Some additional details regarding the errors are:

  • rip –> Remote IP address (the email client residing on my workstation at home)
  • lip –> Local IP address (the mail server software residing on my personal server in the datacentre)
  • session –> a unique session ID provided by Dovecot for a particular client-to-server connection

Armed with this error message, I remembered that the aforementioned ssl_dh setting is handled in the /etc/dovecot/conf.d/10-ssl.conf file (at least in Gentoo Linux; the location may be different on other distributions). I looked at that file, and conveniently enough, there was a comment explaining exactly what needed to be done:

# grep -A5 'SSL DH parameters' /etc/dovecot/conf.d/10-ssl.conf 
# SSL DH parameters
# Generate new params with `openssl dhparam -out /etc/dovecot/dh.pem 4096`
# Or migrate from old ssl-parameters.dat file with the command dovecot
# gives on startup when ssl_dh is unset.
ssl_dh = </etc/dovecot/dh.pem

I made a backup copy of the current dh.pem, and then ran openssl dhparam -out /etc/dovecot/dh.pem 4096.

That openssl command can potentially take quite some time depending on the underlying hardware and level of generated entropy.

With the new 4096-bit certificate in place, I simply restarted Dovecot, and my mail stack worked correctly again. Ultimately, the problem was that my previous Dovecot dh.pem certificate was 2048-bit and that is no longer acceptable. For more information, see the Dovecot SSL page.

Mar 13 2024

1995 Nintendo of America letters about SquareSoft

Over the past few months, I have been going through my basement clearing out old boxes of things kept from my childhood home. I recently came across an envelope that just said “Nintendo” on it. Being an avid retro gamer, my curiosity got the best of me. When I opened the envelope, I found several responses from Nintendo of America to letters that I had obviously written them as a kid.

Out of the letters, my favourite one was from 19 July 1995 where a representative addressed my questions about the possibility of new Final Fantasy games (Final Fantasy IV is, to this day, the most special game to me). The part that makes this particular letter from Nintendo really cool, though, is that the representative, Jonathan, told me about some other games that Square Soft (nowadays, Square-Enix) had in store, including one of their most well-respected games:

The representative even stated that some of these projects “may actually surpass Final Fantasy III” (which was the name of Final Fantasy VI when released in the west).

This letter magically transported me back to better times; times when getting a response from Nintendo of America was undoubtedly the single best thing a kid like me could hope for. I didn’t have to worry about making the mortgage payment, completing those two competing massive projects at work before their respective deadlines, or counting calories to make sure I stayed fit. What I had was the sheer excitement and beguiling anticipation of new JRPGs heading my way.

1995 Nintendo of America letter about SquareSoft, Final Fantasy, and Chrono Trigger
1995 Nintendo of America letter about SquareSoft, Final Fantasy, and Chrono Trigger

If clicking the image for the full version doesn’t work for you, here’s a PDF copy of the letter (~1.5 MiB). 🙂

Cheers,
Nathan Zachary

Aug 24 2023

Mednafen emulator save files when switching discs in multi-disc games

Throughout my adult life, I have always favoured the “retro” video games that I enjoyed during my childhood over newer releases. Nearing the end of my peak gaming interest (in my early adolescence), the original Sony PlayStation hit the markets. With it came multi-disc games where we had to switch discs at one or more points during gameplay.

I hadn’t really given this topic much thought since then, but recently I started playing some of my original PlayStation games on my computer via an emulator (in my case, Mednafen). When it came time to switch to the second disk, the emulator no longer recognised my save file from the first disc; meaning I couldn’t continue the game.

Had I followed the Mednafen documentation for Multi-CD Games, this wouldn’t have been a problem as I would have created an M3U playlist file for the discs. Unfortunately, I hadn’t even considered this potential issue when I started playing the game. Thankfully though, I devised a workaround that allowed me to continue with disc 2 instead of having to start over completely.

Though my explanation below focuses on the PlayStation game Final Fantasy VII using the Medafen emulator within a Linux environment, the process can be generalised to other games, other emulators (e.g. ePSXe or RetroArch), and other Operating Systems (e.g. Windows or Mac OSX).

The overarching problem is that the save files for disc 1 will not be recognised by the emulator as being applicable for any subsequent discs. So, the basic process to fix the problem is:

  • Before loading disc 2 (or later discs) in the emulator for the first time, go to the emulator’s directory for save files and make note of what is present for the game
  • Load disc 2 and use the in-game method for loading your saved game (they should all be empty)
  • Go to the emulator’s save directory again and make note of the placeholder save files for disc 2
  • Copy the contents of the save file entries for disc 1 to the name used for the save files for disc 2

Those steps might seem a bit convoluted, but I think the following example from my computer using Final Fantasy VII will make them clearer. As I played through disc 1 of the game, the only save files related to it were specific to disc 1:

$ ls ~/.mednafen/sav/ | grep VII
Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.0.mcr
Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.1.mcr

At the end of disc 1, I saved my game (as instructed), but when I loaded disc 2 for the first time, all of the save slots were empty. Thereafter, I noticed that there were new save files present:

$ ls ~/.mednafen/sav/ | grep VII
Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.0.mcr
Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.1.mcr
Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.0.mcr
Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.1.mcr

and that the new ones were specific to disc 2, but they didn’t have any of my previous save data in them. At this point, it’s important to recognise the different parts of the filename structure:

Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.0.mcr
Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.1.mcr
Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.0.mcr
Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.1.mcr

  • The red portion is the name of the game (and needs to match the .bin and .cue filenames, including the disc number)
  • The purple portion is the hash for the particular save, and will be randomly generated at initial load
  • The orange portion of 0 or 1 indicates separate save files (possibly because Playstation has two memory card slots)
  • The blue portion is the file extension MCR, which is short for ‘Memory Card’ (taken from the ePSXe emulator)

For the final step of the process outlined above, it is necessary to copy the contents of the two save files for disc 1 into the two save files for disc 2, whilst keeping the filenames for disc 2 as they are. The way I accomplished this task in Linux was to copy the .0.mcr for disc 1 to the name of .0.mcr for disc 2, and then repeat that process for .1.mcr:

~/.mednafen/sav $ cp -v Final\ Fantasy\ VII\ \(USA\)\ \(Disc\ 1\).27d95a6d7ef361c24909f0a5fdf72d11.0.mcr Final\ Fantasy\ VII\ \(USA\)\ \(Disc\ 2\).7b24ee44b5b1f29f85d9e7e79a2b53d7.0.mcr 
'Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.0.mcr' -> 'Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.0.mcr'

~/.mednafen/sav $ cp -v Final\ Fantasy\ VII\ \(USA\)\ \(Disc\ 1\).27d95a6d7ef361c24909f0a5fdf72d11.1.mcr Final\ Fantasy\ VII\ \(USA\)\ \(Disc\ 2\).7b24ee44b5b1f29f85d9e7e79a2b53d7.1.mcr 
'Final Fantasy VII (USA) (Disc 1).27d95a6d7ef361c24909f0a5fdf72d11.1.mcr' -> 'Final Fantasy VII (USA) (Disc 2).7b24ee44b5b1f29f85d9e7e79a2b53d7.1.mcr'

However one chooses to go about this, the goal is the same—to copy the MCR files from disc one over the MCR files for disc 2. The important part is to keep the name of the MCR files for disc 2 the same (including the hash). This will allow the emulator to use them for disc 2.

Using a GUI application (like Windows File Explorer or Mac OSX Finder), it could be done by making a copy of the disc 1 MCR file and then copying the full name of the disc 2 MCR file to use as the new name. There are certainly other methods of accomplishing the task, but the key is having the contents of the disc 1 MCR in the file named accordingly for disc 2 .

I hope that this information is helpful, but if I’m able to provide any further clarification, please just ask in the comments.

Cheers,

Nathan Zachary

The downloading and use of game emulators is legal, but downloading and playing ISO or ROM files is illegal. As such, make sure to use your own backups of games that you personally own in order to avoid any potential legal repercussions in certain countries.