pfSense Support Subscription

Author Topic: ACME and FreeDNS password symbols causing pfSenseConfigurator errors  (Read 138 times)

0 Members and 1 Guest are viewing this topic.

Offline w0w

  • Sr. Member
  • ****
  • Posts: 538
  • Karma: +31/-6
  • kernel panic attack
    • View Profile
When creating new certificate and using method freedns and entering as a password "O?A OuU$?Uy~oe" I am getting an error
Code: [Select]
"
pfSenseConfigurator

    pfSense is restoring the configuration /cf/conf/backup/config-1511681170.xml @ 2017-11-26 09:26:47

"
The other thing is that password should be hidden and it's not.

2.4.3-DEVELOPMENT (amd64)
built on Sat Nov 25 19:44:06 CST 2017
FreeBSD 11.1-RELEASE-p4

The system is on the latest version.
Version information updated at Sun Nov 26 8:07:02 EET 2017
« Last Edit: November 26, 2017, 01:40:05 am by w0w »

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21404
  • Karma: +1437/-26
    • View Profile
Re: ACME and FreeDNS password symbols causing pfSenseConfigurator errors
« Reply #1 on: December 01, 2017, 03:17:48 pm »
That's not entirely unexpected when you use non-XML-safe characters in some fields. We've been slowly trying to fix that up over time but some fields are still not quite ready to handle that.

Side note, you may want to read the new NIST guidelines for passwords which favor length and drop the complexity requirements. You're only making it harder on yourself by using those characters in passwords these days.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline w0w

  • Sr. Member
  • ****
  • Posts: 538
  • Karma: +31/-6
  • kernel panic attack
    • View Profile
Re: ACME and FreeDNS password symbols causing pfSenseConfigurator errors
« Reply #2 on: December 01, 2017, 11:45:03 pm »
AFAIK the NIST guideline sounded like
"Drop the algorithmic complexity song and dance
No more arbitrary password complexity requirements needing mixtures of upper case letters, symbols and numbers. Like frequent password changes, its been shown repeatedly that these types of restrictions often result in worse passwords."
Yes it was about that you can not require a complex password with short length over much more longer password but without any complexity. The length is limited by freeDNS and I am sure in case of limited length complexity always wins  ;)