Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WebConfigurator fails after restore on new hardware / Certificates broken

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    6 Posts 3 Posters 2.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      Starko
      last edited by

      Hello,
      we bought new Hardware for our pfSense box. I did a config.xml backup on the old machine.
      With a texteditor I replaced the old interface names with the new ones (vr1 became em1 .. etc)
      Then I booted the new hardware, skipped the wizard and importet the backup. Firewall rebootet nice with no errors.
      But since then, i'm not able to reach the webinterface. Serial and SSH are working.
      Netstat -an shows me, that the webconfigurator port is not open. In the system.log I see the following:

      
      May 15 03:21:46 fw01 php: rc.bootup: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2014-05-15 03:21:46: (network.c.549) SSL: couldn't read X509 certificate from '/var/etc/cert.pem''
      
      

      When I reconfigure LAN interface in the Mini-Wizard via SSH and Switch Back to HTTP in works fine. But I want to find a solution.

      Backup was taken on pfsense 2.1.1 nanobsd 4g
      Backup was restored on pfsense 2.1.3 nanobsd 4g

      Any idea?

      1 Reply Last reply Reply Quote 0
      • S
        Starko
        last edited by

        Hello,

        I found part of the error. The file /var/etc/cert.pem has some errors in it, after restore of the backup.
        See this line as an example:
        Original

        U2Nod2VsbTETMBEGA1UEChMKTG9naW4gR21iSDEXMBUGA1UEAxMOZncwMS5sb2dp
        

        After Restore

        U2Nod2VsbTETMBEGA1UEChMKTG9naW4gR21iSDEXMB^›A1UEAxMOZncwMS5sb2dp
        

        I was able to fix this, by reverting to HTTP, and then deleting an reimporting this certificate. But every other certificate is also broken..

        Any idea how to fix this?

        1 Reply Last reply Reply Quote 0
        • G
          gharris
          last edited by

          This is still an issue with PFSense 2.1.5!  Trying to stand up a secondary by appropriately editing the primary's config and kept getting bit by this.  Deleting all <ca>sections at the end allowed the secondary to start immediately.  This will be a major issue if I actually have to go back to default.  Is there work on this?</ca>

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            What must be happening here is your text editor is adding line breaks where none previously existed, which breaks the CA. There certainly aren't any issues with backup/restore of certs in general. It is probably the most likely thing for poorly-configured text editors to break in the process though.

            1 Reply Last reply Reply Quote 0
            • S
              Starko
              last edited by

              Sorry I never replied!
              The error I got was selfmade. There has never been an issue with pfsense.

              I worked through our backupped config.xml with Notepad++ and did an Replace all for the changed interface names (vr1 became em1 .. etc)

              I was so lucky that out certs had the part "vr1" in it. So literally replaced parts of our certs, no wonder they were broken. After I replaced the interface names manually, the import worked fine on the new hardware.

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                @Starko:

                Sorry I never replied!
                The error I got was selfmade. There has never been an issue with pfsense.

                I worked through our backupped config.xml with Notepad++ and did an Replace all for the changed interface names (vr1 became em1 .. etc)

                I was so lucky that out certs had the part "vr1" in it. So literally replaced parts of our certs, no wonder they were broken. After I replaced the interface names manually, the import worked fine on the new hardware.

                Thanks for the follow up. Yeah be very careful doing "replace all", as cert contents commonly will match any short string you're replacing, which will of course break the cert. When I edit configs like that, I always make sure to confirm every instance of the string that's being replaced, as there are a variety of possibilities to break things like that.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.