[SOLVED] Re: Certificate Error "format error in certificate's notAfter field"

[George Lane]

On Mon, Sep 12, 2016 at 11:40:44AM -0700, Philip Guenther wrote:
> That value is acceptable...when encoded as required.
> [...]
> The notAfter time is before 2050, so it MUST be encoded as a UTCTIME,
> but it isn't.  You need to fix your CA software to generate
> RFC-compliant certificates when signing them.
>

 Thank you for the prompt and informative reply!

Looking through my build notes (I've learned to keep notes for things
like this), I found that I originally created the CA cert with this
command:

openssl ca -selfsign -config root-ca.conf -in CA/root-ca.csr -out CA/r\
oot-ca.crt -extensions root_ca_ext -enddate 20351231235959Z

As a test, I generated a new root cert with the same process, replacing
  -enddate 20351231235959Z
 with
  -enddate 351231235959Z


The resulting cert, and a server cert that I signed with it, both
validate properly on my OpenBSD server.

I guess I'll now need to re-create all my certs, but at least they'll
be RFC-compliant.

Thanks again,

  George Lane
  Atlanta, US

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: man pages missing in openBSD 6.0

[Otto Moerbeek]

On Sat, Sep 10, 2016 at 02:59:07PM +0200, hom...@mailoo.org wrote:

> OpenBSD 6.0 man pages : adduser, rmuser, user are missing.
> 
> Searching these man pages in man60.tgz returns nothing.

A few man pages ar in the base tarball.

-Otto

man pages missing in openBSD 6.0

[homsky]

OpenBSD 6.0 man pages : adduser, rmuser, user are missing.

Searching these man pages in man60.tgz returns nothing.

Re: Certificate Error "format error in certificate's notAfter field"

[Philip Guenther]

On Mon, Sep 12, 2016 at 10:47 AM, George Lane  wrote:
...
> Running a verify on either a server cert (whose key and CSR were
> generated on OpenBSD, and cert signed on the Debian server) produces an
> error about the notAfter field:
>
> $ openssl verify -CAfile root-ca.crt server.crt
> server.crt: C = US, ST = Georgia, L = Atlanta, O = George Lane, CN = Ge
> orge Lane Certificate Authority
> error 14 at 1 depth lookup:format error in certificate's notAfter field
...
> The root cert has an expiration date of Dec 31 23:59:59 2035 GMT.
> Is there some reasons that this would not be an acceptable value?

That value is acceptable...when encoded as required.


> If it helps, feel free to download a copy of my root cert here:
> http://crt.thinkingguy.com/thinkingguy.com.crt

: corwin; openssl asn1parse -in /tmp/thinkingguy.com.crt  | grep -C1 TIME
  148:d=2  hl=2 l=  32 cons: SEQUENCE
  150:d=3  hl=2 l=  13 prim: UTCTIME   :150815013107Z
  165:d=3  hl=2 l=  15 prim: GENERALIZEDTIME   :20351231235959Z
  182:d=2  hl=2 l= 115 cons: SEQUENCE
: corwin;

Note that the second time there, the "notAfter" value, is encoded as a
GENERALIZEDTIME instead of a UTCTIME.  We then turn to RFC 5280,
section 4.1.2.5 where we find:

4.1.2.5.  Validity

   The certificate validity period is the time interval during which the
   CA warrants that it will maintain information about the status of
the-BEGIN CERTIFICATE-
MIICpTCCAY2gAwIBAgIQAQeWnEdmlQvOdG3q61/ONDANBgkqhkiG9w0BAQsFADAP
MQ0wCwYDVQQDDARteWNhMB4XDTE2MDkxMjE4Mzk0NloXDTM1MTIzMTE4Mzk0Nlow
FjEUMBIGA1UEAwwLZXhwaXJlIHRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBANl781Zxn+ifLNx/aBZl8K6Ep9MLdWdvnUinaxaZUl/zWC9jXuboJBXluJ9r
cldyHaowG4GXBT6i2A+j/8qbEK88rzO/OTgvuePVTQoJA+UXvYueG0JvXBJdzZhb
5GYhqQaLwutVZK9ac31DRSD6eWG1amc53GIWU/iST0JsQ56PAgMBAAGjejB4MAkG
A1UdEwQCMAAwCwYDVR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIGwDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwLAYDVR0RBCUwI4IbemVudm0wODgubGFi
LnByb29mcG9pbnQuY29thwQKFjxYMA0GCSqGSIb3DQEBCwUAA4IBAQBj6gUfWEnO
7TrTki0EhsvLA01G04na4pQ+QHP1hBKnRv/bqs/afnDm5JVZh39MQV0tO4LtpF7F
iAz20mJWsSF+yJvvm5RIQoUAn/JDF4lQEUyDV6wALLNMC3nEJAhpSscqRcZht4qW
UDAieJk5A7Pv6TJX+zxi2/vR2JH7XpsoNhiErCMleJU2pPNzEr2MeBxDxvmUT/zH
pcXypyT9fb95pVu1VCaV7AI4MM1lTivQNFW4uTqnNW3aRNMRMMAymWcHHsQUPu4T
2ndnB/w7xf8973nOLshboJLEGdMVxHVkvTcPsUppuphiNwDJJ5bfvRlKrPqFTPVF
yJmxy+1yk41u
-END CERTIFICATE-
   certificate.  The field is represented as a SEQUENCE of two dates:
   the date on which the certificate validity period begins (notBefore)
   and the date on which the certificate validity period ends
   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
   GeneralizedTime.

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.
   Conforming applications MUST be able to process validity dates that
   are encoded in either UTCTime or GeneralizedTime.


The notAfter time is before 2050, so it MUST be encoded as a UTCTIME,
but it isn't.  You need to fix your CA software to generate
RFC-compliant certificates when signing them.


Philip Guenther

Certificate Error "format error in certificate's notAfter field"

[George Lane]

I have my own PKI running on a Debian 8 server (that I set up using
this tutorial:
http://pki-tutorial.readthedocs.io/en/latest/index.html).

Certificate creation and signing has worked fine on all
my Linux- and Windows- based servers and clients, but when I try to
use the certs on OpenBSD 6.0 (httpd, openvpn) nothing works. I'm not
sure if it's a problem with the certs themselves, a compatibility
problem between OpenSSL and LibreSSL, or something else.


Running a verify on either a server cert (whose key and CSR were
generated on OpenBSD, and cert signed on the Debian server) produces an
error about the notAfter field:

$ openssl verify -CAfile root-ca.crt server.crt
server.crt: C = US, ST = Georgia, L = Atlanta, O = George Lane, CN = Ge
orge Lane Certificate Authority
error 14 at 1 depth lookup:format error in certificate's notAfter field

$ openssl verify -CAfile root-ca.crt root-ca.crt
root-ca.crt: C = US, ST = Georgia, L = Atlanta, O = George Lane, CN = G
eorge Lane Certificate Authority
error 14 at 0 depth lookup:format error in certificate's notAfter field

The man page informs me that error 14 indicates "The certificate notAfter
field contains an invalid time." I'm unable to reproduce this on my
other servers, though. Here are the same commands run against the same
certs on the Debian server:

$ openssl verify -CAfile root-ca.crt server.crt
server.crt: OK

$ openssl verify -CAfile root-ca.crt root-ca.crt
root-ca.crt: OK

Even opening the cert on the cert management console on Windows 7
displays no apparent errors.

The root cert has an expiration date of Dec 31 23:59:59 2035 GMT.
Is there some reasons that this would not be an acceptable value?

If it helps, feel free to download a copy of my root cert here:
http://crt.thinkingguy.com/thinkingguy.com.crt

  George Lane
  Atlanta, US

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: Building OpenBSD 6.0 -stable - Error

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/04/16 04:35, STeve Andre' wrote:
> On 09/03/16 11:32, Harald Dunkel wrote:
>> On 09/03/16 12:40, Ted Unangst wrote:
>>> there's some repo surgery in progress. it should be fixed eventually.
>>> 
>> What exactly does this mean?
>> 
>> 
> It means that something went wrong, and steps were being taken
> 
> to fix it.

Thanx for your response. I stumbled over the "eventually".

BTW, thanx for 6.0. This DVD box has the coolest cover ever.
Keep on your good work.


Regards
Harri

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJX1tzsAAoJEAqeKp5m04HL8BYH/Alo6pSp1zRC25xm5ZeZJC2q
QhUtjxCyl8YbAG44CQxZTKfYw7zd2rmuh2J/rqZpOADAZuV0nMM8ggzwgghw5t4t
9LBDfx2L1PQ8Q2/TOgBCi0WSZxMQRJTv5PIt42QHeOAPWkKXR12v2mslHzoCht4m
+n6o1XiXMsNjAP89ux5Pj1ofoEXQKVel8T6Q4YKOmuksJ2SdoqhSP28hNjxpkgbY
FZpK6D+EJsnbniSXwDrqD4SUTX9xjYtDWVs4xLGp/wPq/slyTKGvLmSnF0LxIIDe
Mbxa0HnjBhYdULGeuU41plNVyr8CGDVC37BqCR8kH+ES8AMuSg/lIWL6aDoITlY=
=GueP
-END PGP SIGNATURE-

Re: UPS, Network UPS Tools and UPD(4)

[Lawrence Wieser]

Todd/Stuart, thanks for the responses. Permissions set correctly on
/dev/usb1 -- the device the UPS is connected to. And I had  been through
the package readme. A couple of times!

As is often the case I was making this much more complicated than it was.
The NUT package installer created the directory /etc/nut:

drwxr-x---  2 root  wheel

When `upsd` was trying to read the `ups.conf` file in /etc/nut it was
getting a permissions error. Fixed now and upsd is running fine.


On Sun, Sep 11, 2016 at 9:35 PM, Lawrence Wieser 
wrote:

> I have a CyberPower UPS that my OpenBSD 5.8 system sees just fine at
> uhidev0 on upd0. But the `usbhid-ups` driver for NUT is unable to talk to
> it.
>
> There are a handful of older comments in the lists that offer a couple of
> alternatives. One involved disabling the upd driver and messing with usb
> quirks. The other involved a revised NUT driver that talked directly to
> upd. If there’s a way for NUT to talk directly to UPD I haven’t found
it.
> What’s the current preferred approach? Or am I better off with a serial
> cable?
>
> Thanks for any insight

Re: xenocara/app/cwm: sticky command

[Okan Demirmen]

On Sat 2016.09.10 at 01:06 +0430, Ali Farzanrad wrote:
> Hi,
> 
> It seems that cwmrc(5) could not change default key binding for sticky
> command and whenever I try to bind keys to sticky, I receive "syntax error".
> 
> I check the codes and found out that in parse.y file "sticky" is a keyword.
> 
> I don't know which is the best patch for this problem, but this patch works 
> for me:

Ah, nice catch! - guess the default keybinding worked for everyone for
quite a long time :)  Thanks for the patch suggestion, though I'll
likely switch to just 'stick' to keep in line with other actions, like
'freeze', 'hide', raise', 'lower', etc...I'd prefer to change the group
meaning of 'sticky' but that breaks most people's config :(

Thanks,
Okan

> Index: conf.c
> ===
> RCS file: /usr/cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.204
> diff -u -p -r1.204 conf.c
> --- conf.c13 Aug 2016 09:59:48 -  1.204
> +++ conf.c9 Sep 2016 19:50:22 -
> @@ -207,7 +207,7 @@ static const struct {
>   { "CM-g",   "grouptoggle" },
>   { "CM-f",   "fullscreen" },
>   { "CM-m",   "maximize" },
> - { "CM-s",   "sticky" },
> + { "CM-s",   "togglesticky" },
>   { "CM-equal",   "vmaximize" },
>   { "CMS-equal",  "hmaximize" },
>   { "CMS-f",  "freeze" },
> @@ -408,7 +408,7 @@ static const struct {
>   {.i = (CWM_CLIENT_RCYCLE | CWM_CLIENT_CYCLE_INGRP)} },
>   { "grouptoggle", kbfunc_client_grouptoggle, CWM_CONTEXT_CLIENT,
>   {.i = CWM_KBD}},
> - { "sticky", kbfunc_client_toggle_sticky, CWM_CONTEXT_CLIENT, {0} },
> + { "togglesticky", kbfunc_client_toggle_sticky, CWM_CONTEXT_CLIENT, {0} 
> },
>   { "fullscreen", kbfunc_client_toggle_fullscreen, CWM_CONTEXT_CLIENT,
>   {0} },
>   { "maximize", kbfunc_client_toggle_maximize, CWM_CONTEXT_CLIENT, {0} },
> Index: cwmrc.5
> ===
> RCS file: /usr/cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.61
> diff -u -p -r1.61 cwmrc.5
> --- cwmrc.5   12 Jul 2015 14:31:47 -  1.61
> +++ cwmrc.5   9 Sep 2016 20:12:10 -
> @@ -301,7 +301,7 @@ Raise current window.
>  Label current window.
>  .It freeze
>  Freeze current window geometry.
> -.It sticky
> +.It togglesticky
>  Stick current window to all groups (same as assigning to nogroup).
>  .It fullscreen
>  Full-screen current window (gap + border removed).

Re: sockaddr_in initialization in ttcp (possibly other programs affected)

[Jeremie Courreges-Anglas]

Philip Guenther  writes:

> On Tue, 6 Sep 2016, Héctor Luis Gimbatti wrote:
>> I post this to .misc since some other (than ttcp) programs might not
>> work in recent versions of OBSD.
>>
>> In OBSD 5.6 I am able to run ttcp.
>>
>> $ uname -a
>> OpenBSD pez.etale.com.ar 5.6 GENERIC.MP#333 amd64
>> $ ttcp -r -s
>> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
>> ttcp-r: socket
>>
>> In OBSD 5.9 and 6.0 I am not able to run it (sadly I do not have running
>> machines with 5.7 nor 5.8).
>
> The change was in 5.9, with this commit to in_pcb.c:
>
> 
> revision 1.178
> date: 2015/09/11 13:59:27;  author: vgross;  state: Exp;  lines: +3 -7;
> commitid: NyNuX1q0M9Dwr560;
> Stricter checks on sockaddr content when binding PF_INET sockets.
>
> Ok mpi@
> 
>
> Unless this is just the most recent in a series of similar reports, I
> doubt we'll back this out or revise the check; it's just old code, written
> in the slightly sloppy style of the time.
>
>
>> Looking at the code in ttcp.c the problem seems to be that the field
>> sin_family in the structure sockaddr_in (sinme) is not initialized.
>>
>> By adding sinme.sin_family = AF_INET; before bind(...) the program works
>> fine.
>
> No specific maintainer on the port, so I suggest you send your diff to
> po...@openbsd.org, so it can be included in ports and packages going
> forward.

+1, misc is not for bug reports.

Anyway, I went ahead and deleted net/ttcp.  It was old, unmaintained
code, and showed scary compile-time warnings (implicit declaration of
malloc for example).  For better alternatives, see tcpbench in base or
net/iperf in ports.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Routing 10-40 Mpps on OpenBSD

[Stefan Sperling]

On Sun, Sep 11, 2016 at 05:46:48PM +, K K wrote:
> Chelsio NIcs: Chelsio T540-CR (although not sure there is an OpenBSD driver)

There is no driver for these cards. There used to be a work-in-progress
driver but it was never finished and hence deleted one year ago.

CVSROOT:/cvs
Module name:src
Changes by: clau...@cvs.openbsd.org 2015/09/11 07:35:15

Modified files:
sys/dev/pci: files.pci 
Removed files:
sys/dev/pci: if_che.c 

Log message:
Remove the unfinished che(4) driver for Chelsio 10G cards. I lost interest
fixing this long ago.

Re: UPS, Network UPS Tools and UPD(4)

[Stuart Henderson]

On 2016-09-12, Lawrence Wieser  wrote:
> I have a CyberPower UPS that my OpenBSD 5.8 system sees just fine at uhidev0
> on upd0. But the `usbhid-ups` driver for NUT is unable to talk to it.
>
> There are a handful of older comments in the lists that offer a couple of
> alternatives. One involved disabling the upd driver and messing with usb
> quirks. The other involved a revised NUT driver that talked directly to upd.
> If there’s a way for NUT to talk directly to UPD I haven’t found it.
> What’s the current preferred approach? Or am I better off with a serial
> cable?
>
> Thanks for any insight

Did you follow the instructions in the pkg-readme file that pkg_add 
pointed you at after it installed the package?