element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Blog Do-It-Yourself Certificate Authority on a Raspberry Pi
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Former Member
  • Date Created: 26 Aug 2016 3:15 PM Date Created
  • Views 6078 views
  • Likes 8 likes
  • Comments 4 comments
Related
Recommended
  • cryptography
  • flask
  • python 3
  • raspberrypi.
  • certificates
  • rpi3
  • pi-zero
  • ssl
  • rpi2
  • bash
  • pi zero w
  • crypto
  • iot
  • sqlite
  • cert
  • dnspython
  • tls
  • feature_tutorial

Do-It-Yourself Certificate Authority on a Raspberry Pi

Former Member
Former Member
26 Aug 2016

On github, I created a Do-It-Yourself Certificate Authority project (https://github.com/texadactyl/diyca), suitable for unit testing (developer testing) just prior to entering integration system testing with a wider audience: more developers, testing organization, end-users, and/or auditors.  A web server approach is used in obtaining an X.509 certificate signed by the unit testing Certificate Authority ("Calvin"), based on a Certificate Signing Request (CSR) provided by the user, employing a web browser (Firefox, Safari, etc.).

 

The inspiration of this project is my own personal technical history and the myriad of Internet of Things (IoT) projects.  My 0bservation of undesirable patterns:

  • No data security at all: (1) no authentication of the endpoints, (2) no message integrity checking, and (3) data is transmitted over the network in clear-text.
  • Partners are using weak cryptography (E.g. RC4 or Single-DES) and there is no secure methodology of installing or managing the secret keys.  E.g. coding the secret keys as program constants.
  • Partners are using strong secret key cryptography but there is no secure methodology of installing or managing the secret keys.  E.g. The secret keys are never changed.

 

Even when developers agree to securely use public key infrastructure and strong cryptography, I have seen cases where they stub this aspect out of their project during unit testing.  This just puts off the inevitable and may cause project delays when the stubs are later replaced with operational code.  Better to design and develop a project from the very beginning as it is intended to be in production.

 

To install, just follow the instructions in https://github.com/texadactyl/diyca/blob/master/docs/preparation_notes.txt.  I use diyca on a Raspberry Pi 2 (1GB RAM) and Raspberry Pi Zero W but I believe that it will operate just as well on earlier models with 512MB.  Ditto for Beagle Bone Black or a Pine A64(+).  So, if you have an "old guy" gathering dust somewhere, it might be worth installing this project on it.  Of course, this project could share space on an existing server system on your LAN that understands Bash scripts and Python.

 

Note that the preparation notes assumes that one is performing a ground up installation.  Of course, one could add this project to an existing installation.

 

Once the `git clone` step from the preparation notes is executed, the diyca tree will look like this:

image

 

The "example.users" folders contain 2 SSL applications: alice (client) and bob (server).  A 3rd application (datagen.py in the alice folder) has been supplied to generate data that alice transmits to bob (who echoes it back verbatim).

 

Once the diyca web server is running, it will respond to HTTPS requests at the IP address of the machine where it is running and at the configured port ("8080" is the default).  The initial screen (User Login):

image

You need to register as a user before signing forms so click on the register link to obtain the register form:

image

Once registered, you are automatically logged in.  The main menu appears:

depictedimage

The pull down function list gives you 3 choices:

  • Certificate Signing Request (CSR)
  • Change Password
  • Logout

 

The CSR function is what alice and bob need to be able to run:

image

The alice.csr file has already been browsed from the example.users/certs folder on my machine.  Clicking on the submit button causes alice.csr to be uploaded to the web server, signed, and then alice.crt is downloaded.  After that, I had to move the alice.crt from $HOME/Downloads to the example.users/certs folder for the purpose of using it in executing alice.  Ditto for bob.  See README.txt in the example.users folder regarding the alice-bob duo of applications.

 

Feel free to contact me for inquiries and issues, especially if you find any bugs.  Suggestions for improving the Python code, HTML, CSS, Javascript, Bash scripts, configuration files, choice of web infrastructure (Flask), the examples, and whatever else are most welcome.

  • Sign in to reply

Top Comments

  • Former Member
    Former Member over 9 years ago in reply to Workshopshed +2
    Workshopshed I take it that for this weather server, you didn't need to provide a client certificate, and your "HTTPS client" (?) accepted the SSL-server certificate as-is. Self-signed? Probably. Anyways…
  • Workshopshed
    Workshopshed over 9 years ago in reply to Former Member

    It was the third party Yahoo weather service so I did not have any control over that. There was no requirement for a client certificate.

     

    I validated the certificate against the public CA that had already been downloaded from a trusted source.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Former Member
    Former Member over 9 years ago in reply to Workshopshed

    Workshopshed  I take it that for this weather server, you didn't need to provide a client certificate, and your "HTTPS client" (?) accepted the SSL-server certificate as-is.  Self-signed?  Probably.

     

    Anyways, if you have a look at the example.users subfolder of this project, you'll find an SSL client called "alice".  Alice has an application configuration file that looks like this:

     

         [everything]

         my_crt_file: ../certs/alice.crt          # Public certificate with embedded public key

         my_key_file: alice.key                  # Private key

         ca_crt_file:  ../certs/diyca_calvin.crt  # Trusted CA that alice and bob share

         server_addr: localhost                  # bob is on this host

         server_port: 32767                       # bob is listening at this port

         session_timeout: 60                     # Governs how long alice will wait for a reply message from the server (bob)

         flag_verbose: False                     # Simply governs debug logging

     

    A Trusted Certificate Authority (CA) to both alice and bob, "calvin", signed alice's Certificate Signing Request (CSR), resulting in alice's signed certificate (CRT).  Ditto for bob.  Because alice and bob possess a certificate signed by a common Trusted CA, they are able to mutually authenticate each other during the SSL session set-up.

     

    Note that in real life, they don't have to have their certificates signed by the SAME CA.  It could be 2 different CAs (usually the case).  The requirement is that during SSL session initiation, bob presents a certificate signed by a CA that alice trusts (CA-1) and alice presents a certificate signed by a CA that bob trusts (CA-2).  In this project, calvin = CA-1 = CA-2.  Yes, a shortcut but legal.

     

    As an IoT application, alice is a simple SSL client that sends a request and waits for a reply or a session timeout notification.

     

    Bob is a bit more sophisticated.  He waits on a select-socket list of events so that he can service multiple requests in tandem.  I could have used a multi-threaded model instead but I decided to keep bob simpler for the sake of demonstrating the server as simply as possible and yet make it realistic.  Bob's application merely copies the request to the reply (dumb, yes).

     

    If you find any value in any of this, help yourself.  If you have any questions, issues, or suggestions, please contact me so I can improve the github project and alert some pals in Asia.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Workshopshed
    Workshopshed over 9 years ago

    I found this last year when I was doing the Enchanted Objects design contest. There was a strong emphasis on IOT security for the competition but I really struggled to find information. Most of the examples dismissed security as "you could add that if you wanted".

     

    I eventually got a HTTPS client to validate the server certificates and read the weather. But that kind of thing should be the default option and people should be struggling to turn it off not the other way around.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Former Member
    Former Member over 9 years ago

    Most likely, you'll have quite a few spare cycles on your "headless" SoC running the diyca web server.  If you are a boinc application fan like me, you can launch the boinc-client services without using a desktop (assuming you took my suggestion of using Jessie-Lite).

     

    I logged into my Raspberry Pi 2 and did the following:

    (1) sudo apt install boinc-client   # Use `yum` if you are on an RPM-oriented system

    (2) sudo vi /etc/boinc-client/remote_hosts.cfg   # Replace "vi" with your favorite editor

          Append the file with the IP addresses of your home computers that have desktops for launching boinc-manager.

          The IP addresses should be unchanging (fixed).

    (3) Restart boinc-client (or reboot)

     

    On your desktop computer,

    (1) Launch boinc-manager

    (2) File > Select computer

    (3) In the "BOINC Manager - Select Computer" pop-up, set the "Host name" to the IP address where boinc-client is running.  Ignore the "Password" field.  Press OK.

     

    You should now be remotely connected to the boinc-client from your desktop.  Add some projects!  (E.g. SETI@Home).

     

    Note that if you do add a desktop (XFCE, LXDE, Mate, etc.), then you have the option to install the boinc-manager GUI and operate the GUI on the same computer where boinc-client is running.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube