Navigation

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

    Certificate import help

    General pfSense Questions
    4
    9
    2446
    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.
    • V
      vsecgod last edited by

      My goal is to use my microsoft server 20082012 essentials CA as my root and issue certificates through there to use for OpenVPN remote access.  I don't wish to use pF as a root since I've already got an established CA with my microsoft box.  I have setup a mock lab consisting of a simple 20082012 essentials server and a pf VM, since I wanted to test this all out before committing changes to my live servers.

      My issue is, when I exported my root CA from the test CA server and used openssl to view the cert as binary, I copied and pasted the info it spit out and when I imported it into the test pf box via certificate manager, it came up with an error (attached) but it looks like it still imported it but without a "valid until" date.  I don't know if it was the binary conversion with openssl or if this is a known issue.  Any assistance is greatly appreciated!


      1 Reply Last reply Reply Quote 0
      • M
        mir last edited by

        Your certificate needs to be exported in PEM format for you to be able to import it. If the certificate is in PEM format maybe this is what have hit you:

        When saving the certificate to a pem file, make sure you are using the correct form of line termination, pem files use the unix flavor, of terminating lines with a single "Line Feed" charecter, while some text editors use the windows flavor of two charecter line termination. If your PEM file was saved on windows, you can fix it in a unix command line with the tr (translate tool), this will remove the second line termination charcter used on windows:
        $ tr -d '\r' < original.pem > fixed.pem

        1 Reply Last reply Reply Quote 0
        • V
          vsecgod last edited by

          • Installed a fresh copy of server 2003 & 2008, created a CA, exported the root cert, imported into pf just fine with no errors

          • Took my existing test copy of 2012 essentials I made earlier, removed the CA role and deleted the root certificate, re-created the CA role and root cert, ran the export and pf accepted it with no issue!

          • so to rule out if there was something fishy with the way server 2012 essentials creates the original root cert (when you first install the OS it automatically creates the CA and root cert for you), I installed sophos UTM and imported the original root cert and it took with no issue on that box.

          • re-created another copy of server 2012 essentials just to ensure my first VM wasn't an issue, and it also failed on the original root certificate import into pf

          testlabRootCA.cer.txt

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned last edited by

            Stop creating certificates with validity beyond 2038.

            1 Reply Last reply Reply Quote 0
            • V
              vsecgod last edited by

              I can't tell if you're trolling but I'll take the bait…

              A) it's a root certificate, so what?
              B) I didn't create it, server 2012 as part of it's automatic configuration..

              1 Reply Last reply Reply Quote 0
              • V
                vsecgod last edited by

                @mir:

                Your certificate needs to be exported in PEM format for you to be able to import it. If the certificate is in PEM format maybe this is what have hit you:

                When saving the certificate to a pem file, make sure you are using the correct form of line termination, pem files use the unix flavor, of terminating lines with a single "Line Feed" charecter, while some text editors use the windows flavor of two charecter line termination. If your PEM file was saved on windows, you can fix it in a unix command line with the tr (translate tool), this will remove the second line termination charcter used on windows:
                $ tr -d '\r' < original.pem > fixed.pem

                Oh and just to add, this didn't work.

                1 Reply Last reply Reply Quote 0
                • M
                  mir last edited by

                  Attached certificate is valid:
                  openssl x509 -in /tmp/testlabRootCA.cer.txt -text -noout
                  Certificate:
                      Data:
                          Version: 3 (0x2)
                          Serial Number:
                              77:88:08:bf:a1:60:1b:a9:41:26:62:46:2b:26:f2:10
                      Signature Algorithm: sha256WithRSAEncryption
                          Issuer: CN=testlab-LAB1-CA
                          Validity
                              Not Before: Nov  2 17:26:52 2014 GMT
                              Not After : Oct 25 17:26:52 2054 GMT
                          Subject: CN=testlab-LAB1-CA
                          Subject Public Key Info:
                              Public Key Algorithm: rsaEncryption
                                  Public-Key: (2048 bit)
                                  Modulus:
                                      00:90:39:00:19:65:78:2b:87:cb:33:57:61:4e:56:
                                      4c:30:b9:5d:7f:b0:f4:ff:62:bd:71:6a:47🆎54:
                                      14:3e:5b:24:df:43:df:98:28:21:ee:da:d2:51:66:
                                      94:7d:49:f9:d7🇩🇪a2:51:ad:ff:5f:73:5e:5f:3e:
                                      71:88:d4:31:49:f0:53:e8:c7:a0:02:7c:d6:14:90:
                                      61:52:3a:52:ce:88:f8:9e:9a:da:a5:60:dd:a1:ef:
                                      43:e3:7d:32:bc:96:a4:e4:90:3d:12:b3:ea:c0:26:
                                      a7:a6:a4:21:b5:fa:bd:63:d2:71:27:01:5e:eb:15:
                                      95:61:c2:11:50:4d:61:63:64:02:88:a1:b0:0d:5b:
                                      5c:0b:b0:00:bc:b0:67:e9:34:c3:ce:c6:53:0e:55:
                                      a9:fc:36:f5:03:8a:40:17:47:0a:c7:a5:96:58:3c:
                                      b8:aa:b9:b4:96:80:d3:01:99:03:28:c9:65:33:06:
                                      5a:fe:b8:53:ba🆎80:05:d1:70:aa:76:4b:82:6c:
                                      b5🇩🇪c2:76:1a:a7:eb:f6:f0:be:42:3b:5f:7e:ce:
                                      a8:db:20:9a:bd:78:fb:6f:c5:90:5b:7b:7a:c2:85:
                                      d0:01:ff:c4:52:05:ff:6a:b1:c7:67:81:ba:2d:cc:
                                      99:73:ee:b5:0d:43:49:27:7e:44:d3:92:c9:c1:03:
                                      0d:cd
                                  Exponent: 65537 (0x10001)
                          X509v3 extensions:
                              X509v3 Key Usage: critical
                                  Digital Signature, Certificate Sign, CRL Sign
                              X509v3 Basic Constraints: critical
                                  CA:TRUE
                              X509v3 Subject Key Identifier:
                                  CD:91:34:61:78:77:B5:91:87:C0:38:B5:6F:55:38:17:EE:C1:DB:D2
                      Signature Algorithm: sha256WithRSAEncryption
                          1e:f6:df:2e:04:54:b2:89:42:ed:cb:09:ce:e0:35:76:bd:da:
                          6a:d1:d9:e7:8c:d8:56:3b:5f:30:ba:d9:6a:b3:19:b8:1e:f5:
                          44:fe:1e:0b:38:88:01:a3:1a:26:4e:20:ba:4e:46:8d:95:03:
                          ef:68:92:45:aa:ba:6c:49:7a:83:f3:7d:3a:25:6b:65:09:42:
                          8c:49:f4:5f:6a:8a:08:df:b2:c6:fa:69:f1:0a:3a:2e:c0:34:
                          4f:87:6e:49:e8:2f:46:a1:b9:e0:e7:22:7b:36:6a:96:b1:80:
                          69:c9:2c:08:1f:00:02:ea:36:2f:99:6d:a0:40:9a:58:e5:52:
                          b7:4d:d4:34:cb:6c:f8:c7:94:ba:2d:40:70:0c:4f:5f:9b:94:
                          39:49:7f:a0:77:a0:60:69:c0:56:fb:c1:2a:92:83:5a:34:ca:
                          4e:03:eb:02:8a:9f:a0:e1:96:2e:56:1d:f1:9d:7e:00:54:9d:
                          4b:90:b6:7f:96:64:6b:20:ea:ed:69:e3:35:a2:e3:c3:df:05:
                          cb:9f:3f:b6:5a:27:a7:0c:b0:85:a5:ca:ce:63:41:56:2a:70:
                          74:47:63:8b:87:91:f2:b0:cb:43:7f:3e:75:6c:bb:f1:6a:ef:
                          8e:60:cf:fc:10:22:dd:6a:fb:c7:50:6c:78:07:98:92:bd:9c:
                          5a🆎0e:1a

                  Maybe the problem is, that another has explained, that pfsense does not allow a certificate which is valid for 40 years. Just a guess I have no proof;-)

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

                    That's a PHP openssl bug with expiration dates that far in the future. https://bugs.php.net/bug.php?id=65698

                    It's been fixed in future PHP versions, so it will work at some point, but yeah for the time being you won't be able to use certs that expire that far into the future.

                    1 Reply Last reply Reply Quote 0
                    • V
                      vsecgod last edited by

                      Ok thanks for that update.  I think MS made it by design (in terms of making the expiration date that far in advance for the default root certificate) due to the fact that the cert is tied to some core services (backup, dashboard console, etc) and since the essentials version is tied to market SMB's, it's probably a pain to re-create the cert after x amount of years…just my 2 cents..

                      Anyways, it still seems to function even though I import it and it displays that PHP error..is it still safe to use (ie, for OpenVPN RA) and that I won't run into major issues or will the system crash or have some adverse effect from me from forcing pf to use a cert it can't half read?

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post

                      Products

                      • Platform Overview
                      • TNSR
                      • pfSense
                      • Appliances

                      Services

                      • Training
                      • Professional Services

                      Support

                      • Subscription Plans
                      • Contact Support
                      • Product Lifecycle
                      • Documentation

                      News

                      • Media Coverage
                      • Press
                      • Events

                      Resources

                      • Blog
                      • FAQ
                      • Find a Partner
                      • Resource Library
                      • Security Information

                      Company

                      • About Us
                      • Careers
                      • Partners
                      • Contact Us
                      • Legal
                      Our Mission

                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                      Subscribe to our Newsletter

                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                      © 2021 Rubicon Communications, LLC | Privacy Policy