1. 21 Jan, 2004 1 commit
  2. 18 Apr, 2003 1 commit
  3. 20 Dec, 2002 1 commit
  4. 12 Dec, 2002 1 commit
  5. 10 Sep, 2002 1 commit
  6. 20 Aug, 2002 1 commit
  7. 15 Aug, 2002 1 commit
  8. 29 Jul, 2002 1 commit
  9. 07 Jul, 2002 1 commit
  10. 02 Jul, 2002 1 commit
  11. 06 Jun, 2002 1 commit
  12. 14 May, 2002 1 commit
    • Leigh B. Stoller's avatar
      Fixes to make sure the certificates are really good for three years. · 6305e238
      Leigh B. Stoller authored
      So, the length of time is set in the .cnf file when signing a cert
      with the CA. However, the length of time the CA is good for is not set
      in the .cnf file (the entry is ignored). Rather, it has to be on the
      command line. So, the certs really were good for 3 years; it was the
      CA that had expired, and once that happens the certs are no longer any
      good. Very bogus.
  13. 14 Apr, 2002 1 commit
  14. 10 Apr, 2002 1 commit
    • Leigh B. Stoller's avatar
      Convert to prompt=no, with per cert config files. This avoids all · 658ee16b
      Leigh B. Stoller authored
      interaction with the user. The main point to note is that for the
      clients, there is a localnode.cnf and a ronnode.cnf. The difference is
      that I encode the type (pcron) in one of the extra fields so that tmcd
      can do a check on it. This is in lieu of per client certs, which would
      be a big pain in the butt right now. As we add other remote groups, we
      will create new config files. I bet this will change over time, as
      we learn more.
      Chad, it would be nice the tiptunnel cert could be generated from this
  15. 04 Apr, 2002 1 commit
    • Leigh B. Stoller's avatar
      First round of ssl'ification of tmcd/tmcc. This needs to be looked at · ffe40d2e
      Leigh B. Stoller authored
      by smarter brains by me (I have asked Dave to look it over). Anyway ...
      I added a top level ssl directory which has a bunch of goo for
      creating certificates and keys.  I currently create a Certificate
      Authority, a server certificate, and a client certificate. The private
      keys for all three are unencrypted, so no password is required. All
      key/cert combos can be installed on boss. The client side needs the
      key/cert pair (in one file), and the CA cert (no key!). There are
      install targets to do this. NOTE, you do not want to create/install
      these without being careful, since you could instantly invalidate all
      the clients!
      I have added the necessary SSL routines to tmcd/tmcc. See the ssl.c
      and ssl.h file. I have set it up so that with all you need to do is
      uncomment three lines in the makefile, and accept,connect,read,write,
      and close are redirected to SSL'ified versions in ssl.c. The current
      security model is that the client and server both "demand" certificate
      verification from the other side (as opposed to just server side
      verification). tmcd reads in server.pem, while tmcc reads in
      client.pem. Both read in the emulab.pem (CA cert with no private
      Initial testing indicates I have done this at least partially
      correctly. Whoever invented this stuff has a really twisted mind
      though. There are some questions at the top of ssl.c that need to be
      Oh, also redid all the syslog stuff throughout tmcd.