csr-proxy

Simple service to sign the clients' CSR via the ACME server

https://github.com/gufolabs/csr_proxy

Science Score: 44.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
    Found CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Academic email domains
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (11.0%) to scientific vocabulary
Last synced: 10 months ago · JSON representation ·

Repository

Simple service to sign the clients' CSR via the ACME server

Basic Info
  • Host: GitHub
  • Owner: gufolabs
  • License: other
  • Language: Python
  • Default Branch: master
  • Size: 742 KB
Statistics
  • Stars: 0
  • Watchers: 1
  • Forks: 0
  • Open Issues: 0
  • Releases: 1
Created over 2 years ago · Last pushed over 2 years ago
Metadata Files
Readme Changelog Contributing Funding License Code of conduct Citation Codeowners Security

README.md

CSR Proxy

CSR Proxy is a simple service to sign the clients' CSR via the ACME server.

PyPi version Python Versions License Build Sponsors

Ruff

Documentation: https://docs.gufolabs.com/csr_proxy/

Source Code: https://github.com/gufolabs/csr_proxy/


The self-signed certificates are no longer sufficient, posing challenges in distributing trial and evaluation versions of software with web interfaces. To address this, software publishers typically consider the following options:

  1. Delegate Certificate Signing to the User:
- Pros: Gives control to advanced users.
- Cons: Requires user knowledge of PKI, complex infrastructure, or additional expenses.
  1. Generate Self-Signed Certificate with mkcert:
- Pros: Suitable for developers.
- Cons: Compromises system security, demands browser reloading, and adds complexity.
  1. Order a Certificate from Global CA:
- Pros: Secure, but expensive.
- Cons: Violates TLS security principles by exposing the private key.
  1. Use localhost.direct Certificate or Similar Services:
- Pros: Similar to the previous approach.
- Cons: Public exposure of the public key.
  1. Order Separate Certificates for Each User:
- Pros: Secure but time-consuming and costly.
- Cons: Mutual trust issue; the publisher generates and knows the client's private key.
  1. Generate Client's Key and Certificate via ACME Server:
- Pros: Less expensive.
- Cons: Mutual trust issue persists; the publisher generates and knows the client's private key.
  1. Negotiate with ACME Server from Client's Site:
- Pros: Reliable, but requires additional infrastructure setup.
- Cons: Suitable for advanced users, not the default choice.

Considering the need for mutual trust and simplicity in software evaluation, the publisher should generate a private certificate on the user's side without touching it. The published also needs to maintain all necessary infrastructure for the certificate signing. Enter the CSR Proxy.

CSR Proxy Overview

The CSR Proxy is a straightforward service executed on the publisher's side. It:

  • Receives the Certificate Signing Request (CSR) from the client.
  • Proxies the CSR to the ACME server for signing.
  • Handles ACME challenge fulfillment, shielding the end user from complexity.

The sequence diagram is shown below. The primal parties are:

  • Client: An entity demanding the certificate signing.

  • CSR Proxy: The certificate signing service, consists of two parts:

    • API: The client-facing API, performing ACME interaction on behalf of the client. Also performs DNS provisioning.
    • DNS: PowerDNS service, providing a provisioning interface to API and serving DNS requests.
  • ACME: Any RFC-8555 compatible ACME server, like Let's Encrypt.

mermaid sequenceDiagram participant Client box CSR Proxy participant API participant DNS end participant ACME Client->>Client: Generate private RSA key Client->>Client: Create CSR Client->>API: CSR sign request activate API API->>ACME: New order activate ACME ACME->>API: Order authorization deactivate ACME API->>ACME: Get challenges activate ACME ACME->>API: Challenges deactivate ACME API->>DNS: Put _acme-challenges RR activate DNS DNS->>API: RR is ready deactivate DNS API->>ACME: Respond dns-01 challenge activate ACME ACME->>API: Status ACME->>DNS: Query _acme-challenge RR activate DNS DNS->>ACME: _acme-challenge RR deactivate DNS API->>ACME: Check autorization ACME->>API: Authorization status API->>ACME: Finalize ACME->>API: Order status deactivate ACME API->>Client: Signed certificate deactivate API

On Gufo Stack

This product is a part of Gufo Stack - the collaborative effort led by Gufo Labs. Our goal is to create a robust and flexible set of tools to create network management software and automate routine administration tasks.

To do this, we extract the key technologies that have proven themselves in the NOC and bring them as separate packages. Then we work on API, performance tuning, documentation, and testing. The NOC uses the final result as the external dependencies.

Gufo Stack makes the NOC better, and this is our primary task. But other products can benefit from Gufo Stack too. So we believe that our effort will make the other network management products better.

Owner

  • Name: Gufo Labs
  • Login: gufolabs
  • Kind: organization
  • Location: Italy

Gufo Labs is a private consulting company based in Milan, Italy.

Citation (CITATION.cff)

cff-version: 1.2.0
title: Gufo CSR Proxy
message: >-
  If you use this software as part of a publication and wish to cite
  it, please use the metadata from this file.
type: software
authors:
  - name: Gufo Labs
    website: https://gufolabs.com/
  - name: Project's Contributors
    website: https://github.com/gufolabs/csr_proxy
license: BSD-3-Clause

GitHub Events

Total
Last Year

Packages

  • Total packages: 1
  • Total downloads:
    • pypi 17 last-month
  • Total dependent packages: 0
  • Total dependent repositories: 0
  • Total versions: 1
  • Total maintainers: 1
pypi.org: csr-proxy
  • Versions: 1
  • Dependent Packages: 0
  • Dependent Repositories: 0
  • Downloads: 17 Last month
Rankings
Dependent packages count: 10.0%
Forks count: 29.8%
Average: 36.5%
Stargazers count: 38.8%
Dependent repos count: 67.6%
Maintainers (1)
Last synced: 11 months ago

Dependencies

.github/workflows/build-docs.yml actions
  • actions/cache v3 composite
  • actions/checkout v3 composite
.github/workflows/py-tests.yml actions
  • actions/cache v3 composite
  • actions/checkout v3 composite
  • actions/setup-python v4 composite
  • docker/build-push-action v5 composite
  • docker/login-action v3 composite
  • docker/setup-buildx-action v3 composite
  • docker/setup-qemu-action v3 composite
  • pypa/gh-action-pypi-publish release/v1 composite
Dockerfile docker
  • python 3.12-slim-bullseye build
.requirements/deps.txt pypi
  • gufo-acme ==0.3.0
  • starlette ==0.32.0
  • uvicorn ==0.24.0
.requirements/docs.txt pypi
  • mkdocs-gen-files ==0.5.0
  • mkdocs-literate-nav ==0.6.0
  • mkdocs-material ==9.4.8
  • mkdocs-section-index ==0.3.8
  • mkdocstrings ==0.22.0
.requirements/ipython.txt pypi
  • ipython ==8.0.1
.requirements/lint.txt pypi
  • black ==23.1.0
  • mypy ==1.5.1
  • ruff ==0.1.5
  • types-PyYAML ==6.0.12.3
.requirements/test.txt pypi
  • PyYAML >=6.0 test
  • coverage ==7.3.2 test
  • pytest ==7.4.3 test
pyproject.toml pypi
  • gufo-acme == 0.3.0
  • starlette == 0.32.0
  • uvicorn == 0.24.0