HTTPs support on the API

HectorCuesta
HectorCuesta
Community Member
in Secrets Automation

Hi,

There is any timeframe on when support for HTTPs is going to be available on the API?

Thanks.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • James_1P
    James_1P

    Hi!

    The excellent news is that the 1.2.0 release of the Connect server supports TLS at the container level.

    The less good news is that we haven't gotten the documentation for using it published yet.

    The tl;dr of using it is pick one of these two Environment variable configuration options:

    Option 1 – Bring your own Cert

    • OP_TLS_KEY_FILE: path to the private key file.
    • OP_TLS_CERT_FILE: path to the certificate file. This should be the full certificate chain.

    Option 2 – Let's Encrypt

    • OP_TLS_USE_LETSENCRYPT: should be set to any value.
    • OP_TLS_DOMAIN: the (sub-)domain for which to request a certificate. The DNS-records for this domain must point to the Connect server.
  • HectorCuesta
    HectorCuesta
    Community Member

    Oh thats great to know, got it working with https!

    Thanks!

  • ag_ana
    ag_ana
    1Password Alumni

    Thank you for the update @HectorCuesta! And on behalf of James, you are welcome :)

    If you have any other questions, please feel free to reach out anytime.

    Have a wonderful day :)

  • 1PBusinessUser
    1PBusinessUser
    Community Member

    Hi,

    Apologies, this might be an obvious question however do OP_TLS_KEY_FILE: and OP_TLS_CERT_FILE go in your docker-compose.yaml file or somewhere else?

    Thanks.

  • James_1P
    James_1P

    If you are using docker compose then you can set those variables in the environment section for each container

  • 1PBusinessUser
    1PBusinessUser
    Community Member

    Hi James,

    Thanks for your reply.

    In the end I created an .env file and referenced in the docker-compose.yaml file and now API access over https is working! I had to add the following under the op-connect-api ports section:

      - 443:8443/tcp
  - 80:8080/tcp

    and removed to not allow http API access.

      - "8080:8080"

    Would - 80:8080/tcp be save to remove if only API https access is required or could it be need for renewing letsencrypt certifcates?

    Also by default is op-connect-sync only working over http:

    ports:
  - "8081:8080"

    Would that need to be altered for https sync?

    Thanks again!

  • David_ag
    David_ag

    Coming back to close the loop on this -

    Would - 80:8080/tcp be save to remove if only API https access is required or could it be need for renewing letsencrypt certifcates?

    It's safe to remove if you're not using HTTP-based renewal. If you're using DNS validation, for example, then you don't need to open port 80 and should be ok removing that mapping.

    Also by default is op-connect-sync only working over http:

    That port is for the API server to check in on the syncer. Any data between the syncer and the API server is encrypted with a unique key. You can read more about how the data is kept secure in our 1Password security whitepaper (pdf) under the 1Password Connect -> Interprocess Key section (~page 47 at time of writing)

  • 1PBusinessUser
    1PBusinessUser
    Community Member

    Hi again. Thanks for your assistance so far.

    I've had an issue using our own certificate created by a CA.

    I have created a second env file and pointed to that from docker-compose.yaml.

    docker-compose config shows the full path to the private key and certificate chain however it does not seem to be working:

    services:
    op-connect-api:
    environment:
    OP_TLS_CERT_FILE: /home/xxx/1PS/1PS.crt
    OP_TLS_KEY_FILE: /home/xxx/1PS/1PS.key
    image: 1password/connect-api:latest
    ports:
    - protocol: tcp
    published: 443
    target: 8443

    Contents of env file:

    OP_TLS_KEY_FILE=/home/xxx/1PS/1PS.key
    OP_TLS_CERT_FILE=/home/xxx/1PS/1PS.crt

    1PS.crt is the full certificate chain which I have ordered in various ways e.g. cert > intermediates > root or root > intermediates > cert etc. The chain checks out ok when verifying it on tools such as https://tools.keycdn.com/ssl

    docker-compose up -d was use to reload the container after making the changes. In addition docker container ls does not show the 1ps_op-connect-api_1 container as tarted. Using netstat -tulpn | grep LISTEN shows that no web servers are listening on port 443 which makes sense.

    Reverting back to the docker-compose.yaml which is configured for lets-encrypt gets TLS working again however we don't want to expose any external firewall holes to the server and are not using DNS validation.

    Any ideas what could be going on or if I am missing something obvious?

    Thanks!

  • David_ag
    David_ag

    Just so we're on the same page - are you mounting the certificate and key as Docker volumes? Glancing at the config you posted it doesn't look like you are, which means those two files are not available to the Connect API process within the container.

  • 1PBusinessUser
    1PBusinessUser
    Community Member

    I had tried copying the key and cert to the container which didn't work so will try mounting the file as a Docker volume. Docker config is new to me so this has been a valuable learning exercise.

  • 1PBusinessUser
    1PBusinessUser
    Community Member

    Thank you, your latest advice got it working for me. There was already a mounted Docker volume /.op/data, so copied over the files in there and referenced them in the .env file.

This discussion has been closed.